There is no general documentation. Bytes are bytes, hits are hits, etc. If you have a specific example, perhaps I can help.
Well, that's true. I guess I'm loking for validation about the number of blocks and bytes being returned.
Thoughts on this? This is not traffic coming IN from our internet, as it's being blocked - would this be traffic returned back to workstations in the form of block pages??
Well... Bocked doesn't necessaryly mean no traffic is coming IN to your network. First of all, there are 4 locations to measure bytes. Two up (client -> proxy) and (proxy -> web server). Two down (web server -> proxy) and (proxy -> client).
By default Web Gateway only logs bytes_to_client (proxy -> client). So all blocks have a few bytes (the block page sent to the user). But if you consider a large zip file that contains detected malware, then the entire zip is still downloaded before blocked. The bytes_from_server will be large (size of the zip), but the bytes_to_client (block page) will be small.
Web Reporter has 3 byte columns, one up, one down, and bytes (sum of the other two). That report displays bytes (sum of up and down). So you need to know what is logged for your up (bytes_from_client, bytes_to_server) and down (bytes_from_server, bytes_to_client) columns. Make sure your logging rules are writing the correct value under the correct header. Web Reporter relies on the logs, so you should always verify that the logs are correct first.
Once you know what is in the logs, you can interpret the data.
1 of 1 people found this helpful
bytes_to_client would represent the block page returned to the user.
That is about an 9k block page for each hit. That's probably accurate.
I suppose you could change your logs to report bytes_from_server instead. That would usually be 0 bytes per block.