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

cffsNN.astaro.com traffic

Hi

Whilst I was monitoring the WAN on my network, with Wireshark, I noticed a
lot of traffic to/from cffsNN.astaro.com (NN from 01 to 22).

Inspection of the packets, targeted to port 80, revealed nothing obvious.

This traffic appears to be triggered by any user accessing a website, though there may be other events not spotted so far.

Searching this board doesnt explain the purpose of this traffic, so I put the question to the experts.

Version is ASG Software 9.210-20

Thanks

Aimee


This thread was automatically locked due to age.
  • That's the cloud-based web filtering category lookups, normal behavior.  The new system (dubbed SXL) will also use cloud lookups, but different servers from the old cffs ones.  This is enabled by default in 9.3xx, and in 9.2/9.1 if you enable web filtering in the UTM Endpoint configuration.
  • Hi
    if I understand you correctly, its looking for updated information to perform the filtering?

    What happens if I block it, the reason being that one of my potential clients wants to use 
    this on a capped service and all this 'extra' traffic will add to the usage.

    Is there a set of default lookups held on the actual system, negating the 'go to the cloud' traffic.

    Hope that makes sense

    Aimee
  • Block categorization?  Consequences depend upon, in part, on configuration.  Disabling category checks for web proxy should(?) stop most of the CFFS traffic (except the periodic "pings"?).  How much data transfer are you seeing for lookups?  In comparison to other traffic too?

    Switching to the (unsupported) local CFFS database required about 400 megabytes of download to start, from what I recall - and occasionally much more if it malfunctioned or didn't complete the download within a time limit.

    See also:  
    How categorization of websites works in Sophos UTM
    Google, site:astaro.org cffs
  • Hi
    had a quick look, and one thing I would like to try is this
    cc set http sc_local_db none
    /var/mdw/scripts/httpproxy restart
    but what is the cc command to enable the sc_local_db ?
    Thanks

    Aimee
  • Google: site:astaro.org sc_local_db

    Don't forget the command line warning:
    NOTE: Any modifications done by root will void your support.
          Please use WebAdmin for any configuration changes.


    Talk to the support providers vendor/Sophos first.
  • Local DB is not supported (they were toying with it before the SXL categorization method became available).  You most likely will have issues, and I don't think they are even updating that local database as an option anymore.

    You should probably just switch to SXL categorization; this generates a little category lookup traffic, but is faster than the old CFF lookups and does maintain a local cache.  Otherwise, just turn off category and reputation filtering.

    The way to do this (If you do not update to 9.3xx or use or enable UTM Endpoint Web Protection) is to log into the console as root, and run this command:

    cc set http use_sxl_urid 1

    You may need to restart the unit / proxy after making that change (I'd recommend it).
  • cc set http sc_local_db none will turn off the local content filter database, which is off by default anyway, so won't do you any good.  Using none, all checks are done on the fly to "cloud" servers.  Setting to mem or disk will copy the current db to the local system (as Bruce said, ~400MB.  After that the system will pull updates for the DB several times daily, but lookups for client traffic are done against that local DB copy.  Read Bruces warnings about this feature above to make an informed decision about its' use.  

    If you will not allow content filter database updates/lookups, there is little point in using the web filtering proxy for category based filtering.  Incorrectly categorized sites would not be fixed for you and the thousands of new sites added to the web daily would not be categorized either, forcing you to allow uncategorized sites.  Let the client know that you'll be crippling a major security/useability feature that they will be paying for, before you block the categorization ability of the system.
  • Hi

    Thanks to all who pitched in, going to try a few options before advising client.

    Aimee