Feat. request: More fine grained bandwidth control

[deajan]

Hello,

Would it be possible to tune bandwidth depending on current time ? Example: backup with full bandwidth at night, and use a bandwidth limit at daytime, which gets enforced as soon as the night is over.

Best regards.

[grke]

Hello,

I think it is an interesting thought, but I cannot immediately picture what this would look like as config options. Do you have any ideas as to how the config would look?

[pablodav]

Hello @deajan @grke

I have some kind of scripts that those these kind of things actually.

The script is too ugly to be shared actually (in my own opinion), and have lot of hardcoded options that should be better provided in config file. Also the actual script is in powershell (because the need was to solve it on windows only for now), but I could propose to create something in python.

I was thinking in the possibility to open a vote to see if this kind of script/program is something that could be of interest to others in burp community.

The basic features I have now are:

• Per location bandwith traffic (reads location ID from AD and sets bandwith dynamically)
• Also changes the bandwith if the client is not in their location or location of the server
• Could be very simple to add parameter to change bandwith based on time.
• Copy last client log with success backup to /path/desired
• Checks the logs and looks for known errors with SSL, like:

  *SSL alert number 51*
  *SSL3_READ_BYTES:tlsv1 alert decrypt error:s3_pkt.c*
  *Error with certificate signing request*
  *check cert failed*
  *e:Will not accept a client certificate request for* -and $_ -like "*already exists*"

• Also checks logs for *unable to authorise on server*
• Also checks for errors logs on server *Error when reading counters from server*
• If some of the errors are found it will also send request for fix (actually with copy of file, but will be required something more advanced like RESTFUL service or something else for these cases)
• Checks the last time a backup was performed (reading date of log file copied on the client) and displays window notification to user warning about the state of outdated backup (when enabled)
• Also have defaults settings like: burp server to use and request to add the client to the server when initial setup is done.

The script changes dynamically burp.conf client file and executes burp -a t, also burp.conf calls this script in options script_pre and script_post.

If someone is interested I will try to share more details of the idea later.

[deajan]

@grke I was thinking of a timer_arg like config option:

bandwidth = xxx bandwidth_timed = yyy bandwidth_timer_arg =Wed,Thu,15,16,17

Normal backup bandwidth = xxx, and on wednesday and thursday from 15 to 17h59, backup bandwidth is yyy.

@pablodav Interesting scripts, maybe sharing them on your git would be a good base :)

[pablodav]

hello @deajan , I have now shared the script and idea in: https://github.com/pablodav/burp_eclient

[grke]

I think doing https://github.com/grke/burp/issues/209 first would be a step towards this.

[ziirish]

Hi,

I think a good starting point would be to have the ratelimit option available per client in clientconfdir files. Then a first iteration for such a feature could look like this:

1. expose a $clientname variable in the configuration parser
2. in the clientconfdir file, add a line like . /some/volatiledir/$clientname/*.conf
3. pass the clientname to backup_script_pre and provide a script that will create the according /some/volatiledir/$clientname/ratelimit.conf file
4. the conf should be re-sourced after the backup_script_pre so the new settings are loaded

[grke]

My impression of the initial idea was that the ratelimit would change within the same backup process.

Whereas, your volatiledir idea would set the ratelimit once per backup process. With this, a long-running backup with a high ratelimit would continue to use high bandwidth once the time has moved on into the low bandwidth part of the day.

[deajan]

Agree with @grke, this is actually what bothers me as of today, long backups that I have to manually stop on the beginning of the day because it eats the bandwidth on non QoS aware networks.