Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Unblocking a category

Hi there,

I'm new to XG,I'm getting the message below. I'm using the default policy.
I want to unblock the category Auctions & Classified Ads.
In Categories, I marked it as acceptable, but it still is blocked.
In the default policy, the line that blocks it is the second one, block Risky Downloads and Suspicious.
I want to allow that category, and still block Risky Downloads and Suspicious.

What am I missing there ?
Thanks.

Blocked request

This is a message from the IT Department.

The web site you are trying to access:
my.ebay.com/.../eBayISAPI.dll
is listed as a site within the category Auctions & Classified Ads

Current Internet Access Configuration for you does not allow visiting sites within this category at this time.

If the website has been erroneously blocked, please submit it for re-evaluation.


You are currently browsing as an unauthenticated user.

Click here to log in



This thread was automatically locked due to age.
Parents
  • Michael,

    traffic is blocked by Web Filter and not from Application filter. Customize the Web Filter been used or create a new one and allow the categories you need.

  • Luk,

    > traffic is blocked by Web Filter and not from Application filter. Customize the Web Filter been used or create a new one and allow the categories you need.

    That's what I think I'm doing, Web -> Policies and Web -> Categories. In categories, I marked the "Auctions & Classified Ads" as acceptable, and it still is being blocked until I turn off the second line in Policies, the one that blocks Risky Dowloads and Suspicious.

     

     

    Then I go to www.ebay.com, click on "my ebay", and I get this :

     

    As short-term shortcut, I do this :

    Then I can go to "My eBay".

    What am I missing ? Thanks for helping an XG rookie.

  • Michael,

    what is the default action of this web filter? Also can you show the firewall rule?

    Thanks

  • Luk,

    > what is the default action of this web filter?

    Block risky downloads and suspicious, on. The category was unproductive before I changed it to acceptable.

    Otherwise it's a fresh install from scratch, I just don't get the logic behind it. Without changing anything, "my ebay" is being blocked and I don't see anywhere why, because there is nothing referencing that category in the rule in the first place.

     

    > Also can you show the firewall rule?

    Here you are, and the details below.

     

    Details when I click on "edit".

  • So I'm still at a loss about what I'm missing here. Could someone tell me what I'm doing wrong ?

  • Michael,

    can you share the XG logs? Firewall, App and Web.

    Thanks

  • Here you go. Nothing in the other logs.

  • This seems to be a bug as I'm having the exact same issue with a clean/standard install.

    I am also wanting to use the Web "Default Policy" with just the default "Risky Downloads" & "Suspicious" User Activities blocked.  Neither of these activities include the "Auctions & Classified Ads" category however when viewing items within Ebay there is a Sophos blocked request message at the bottom of the page claiming the site is listed within the "Auctions & Classified Ads" category.  The only way of removing this is to unblock the "Risky Downloads" & "Suspicious" User Activities.

  • @kc_nz are you in bridge mode or in gateway mode ? I'm surprised this has not popped up before, surely we are not the only two out there to use this combination.

  • I'm running in bridge mode.

  • The root cause is that the URL contains an extension listed within the "System Files" (being the eBayISAP.dll component).

    This is being blocked by the "System Files" category within the "Risky Downloads" User Activity (used within "Default Policy").

    The issue is that the "Blocked request" message is written with website categories in mind, hence why it insinuates that the issue is with the site belonging to the "Auctions & Classified Ads" category... when in fact it's because it feels the user may be downloading a system (DLL) file.

    Not sure what could be done about it... it's a bit of an edge case... however the resulting message is very confusing for administrators and users...

    The "quick win" would be to remove "System Files" from within "Risky Downloads"... or create a new File Type that duplicates the existing "System Files" but without the "dll" extension and use that within "Risky Downloads".

  • You are correct in the issue being that you have said to block System Files, which include all files with the .dll extension.  ebay (and a few other sites) use this ISAPI.dll.

    The best way to fix (leaves the most protection) is go to Web, File Types.  Add a new type, and under Template choose System Files.  Under extension, remove dll from the list.  Call is System Files 2.

    Go to Web, User Activities, Risky Downloads and click the edit icon.  Remove System Files and add in the new System Files 2.


    I wanted, however, to clear up some confusion about the logic chain.
    The category "classification" is informational only, it does not get used in policy decisions.

    For any debugging, start with the Policy.  A policy is executed from top down.  A policy rule (a line within the policy) can include a category, a file type, or a user activity (which is a collection of categories and/or filetypes).

    In this case, the action was blocked.  You should look at the entire policy rule line (which includes two user activities, which drills down to several categories and file types).

    I though that in v16.5 the blockpage would correctly say it was blocked by filetype but maybe not...  In the upcoming v17 all end user pages are being redone and the block page would show the block reason as "System Files".

Reply
  • You are correct in the issue being that you have said to block System Files, which include all files with the .dll extension.  ebay (and a few other sites) use this ISAPI.dll.

    The best way to fix (leaves the most protection) is go to Web, File Types.  Add a new type, and under Template choose System Files.  Under extension, remove dll from the list.  Call is System Files 2.

    Go to Web, User Activities, Risky Downloads and click the edit icon.  Remove System Files and add in the new System Files 2.


    I wanted, however, to clear up some confusion about the logic chain.
    The category "classification" is informational only, it does not get used in policy decisions.

    For any debugging, start with the Policy.  A policy is executed from top down.  A policy rule (a line within the policy) can include a category, a file type, or a user activity (which is a collection of categories and/or filetypes).

    In this case, the action was blocked.  You should look at the entire policy rule line (which includes two user activities, which drills down to several categories and file types).

    I though that in v16.5 the blockpage would correctly say it was blocked by filetype but maybe not...  In the upcoming v17 all end user pages are being redone and the block page would show the block reason as "System Files".

Children
  • Can you detail the thought process that allowed you to identify the file name that was being blocked ? What I did to narrow it down was totally un-scientific; I disabled items randomly hoping to identify which one was causing the problem. There should be a better way than poking the patient to figure out where it hurts.

  • Since I know the product really well, its easier for me...

    I'd look at the log and see that only one URL is blocked and all the others are allowed.

    There are the following typical reasons for block (not a complete list):
    category
    filetype
    virus / ATP / heartbeat
    SSL/certificate
    error that logs itself a block

    First test is to turn off all rules.  If it starts working then you know it is likely a policy issue and not an error issue.

    Since the log indicates that other requests for the same category passed, that is ruled out.
    Not HTTPS, so those a ruled out.
    Unlikely that there is a virus or ATP, and if there were they would have other alerts.

    That leaves filetype and maybe still errors that log themselves as a block.  I happen to know that my policy blocks certain filetypes (if it didn't then I would skip this check), and that disabling policy makes it work.

    Block page and log said
    my.ebay.com/.../eBayISAPI.dll

    I happen know that the way URLS are parsed is that there is a domain, then path/file, then a query string.  Query string is not used in filetype detection, and the last part of the path is the file.
    my.ebay.com/.../eBayISAPI.dll

    Seeing a dll immediately raises a red flag.

    Then either play with policy to narrow it down, or just dig through the UI to map out to the file types, extensions and mime types.

  • Well I hit this issue today, the first day to launch our new XG 310.

    However, I am confused on what is the 'best' or 'least impactful' way to make MyEbay work but not compromise overall system file scanning?

    Could someone please outline the step for this noob?

    Thanks,

    RH

  • In re-reading I saw this from Michael:

    The best way to fix (leaves the most protection) is go to Web, File Types.  Add a new type, and under Template choose System Files.  Under extension, remove dll from the list.  Call is System Files 2.

    Go to Web, User Activities, Risky Downloads and click the edit icon.  Remove System Files and add in the new System Files 2.

    So I just want to confirm this is the 'fix'

    Thanks again,

    RH