max_children per operation

[andrekeller]

Currently burp has a setting to restrict how many children processes may run concurrently.

It would be nice if this could be made a bit more granular, to allow restores when all children are busy with backups.

So being able to set different max_children for backup (maybe even phase 1/2 and phase 3/4) and restore/list would help a lot.

[grke]

Should be done in conjuction with #450.

[grke]

A big difficulty is that the server doesn't know what sort of process (backup/restore/etc) it is forking for before it has forked a child.

[grke]

I have implemented this, and now running tests before I push to github.

For example, the server conf can have:

port=4971
max_children=10
port=5971
max_children=3

You can have an arbitrary number of port/max_children pairs.
(If you want to set all of max_children the same, just specify max_children once)
Each port will handle any non-status server request. You will need to set the client config to define which port it will use for each action. For example, you can just set this is in the client config to make all requests go to one port:

port=4971

Or, you can specify specific ports for backup/restore/verify/list/delete options, like this:

port_backup=4971
port_restore=5971
port_verify=6971
port_list=7971
port_delete=8971

Or, you can specify the default port to connect to, and only change one of the specific ones:

port=4971
port_backup=5971

In this case all requests, except for backups will go to 4971.

port_restore and port_verify are kind of related, so if unset, port_verify will default to whatever port_restore is set to.

Additionally, you can also now have an arbitrary number of status_port/max_status_children pairs on the server.

Practical example follows:

My server output with burp-server.conf:

port = 4971
max_children = 5
port = 5971
max_children = 2
status_port = 4972
max_status_children = 5
status_port = 5972
max_status_children = 2
stdout=1

root@small:/home/graham/burp# burp -c /etc/burp/burp-server.conf -F
2017-05-13 04:57:23: burp[14554] server :::4971 (max 5)
2017-05-13 04:57:23: burp[14554] server :::5971 (max 2)
2017-05-13 04:57:23: burp[14554] server status ::1:4972 (max 5)
2017-05-13 04:57:23: burp[14554] server status ::1:5972 (max 2)

My client output with burp.conf:

port = 4971
port_backup = 5971
status_port = 5972

root@small:/var/spool/burp# burp -a b
2017-05-13 05:01:12: burp[15370] Connecting to ::1:5971
2017-05-13 05:01:13: burp[15370] auth ok
...etc...

Causes output on server:

2017-05-13 04:59:29: burp[15362] Connect from peer: ::1:39500
2017-05-13 04:59:29: burp[15362] 0/2 child processes running on port 5971
2017-05-13 04:59:29: burp[15362] Child 1 available
2017-05-13 04:59:29: burp[15362] forked child on port 5971: 15365
2017-05-13 04:59:29: burp[15365] auth ok for: testclient
...etc...

[ziirish]

Hi,

This sounds like a great feature. The drawback I see is the configuration is getting quite complicated.

I'll have to rework the burp-ui config parser in order to deal with these changes.

My understanding is there are now some pairs of settings that "interact" with each other:

• port / max_children
• port_* / max_children
• status_port / max_status_children

My parser tries to edit settings where appropriate instead of dumping a new configuration in order to keep user comments for instance.

There is a known issue with this kind of setup though:

setting1 = a
#setting2 = b
setting2 = d

If you set setting2 = c in burp-ui, the resulting config will look like:

setting1 = a
setting2 = c
#setting2 = d

People might expect that the #setting2 = b remain unchanged(?)

All that to say, burp-ui has some difficulties to deal with order so right now, with this new config I have no way to deal with something like:

status_port = 5972
max_status_children = 2
status_port = 6972
max_status_children = 6

The simple solution is to just dump a new configuration that overrides the old one with the right settings, but users will loose their comments.

P.S.: I am not complaining about this new feature, I am just explaining here the current burp-ui limitations so that I can reference this issue later if people face the problem.

[andrekeller]

@grke This sounds really promising. Once you have pushed to master, I'm happy to test this.

[grke]

Ziirish, although I described the settings being in pairs, that is not actually important internally to burp. The following all result in the same behaviour:

port=1111
max_children=5
port=2222
max_children=5

port=1111
max_children=5
port=2222

max_children=5
port=1111
port=2222

port=1111
port=2222
max_children=5
max_children=5

port=1111
port=2222
(this one is because max_children=5 is the default)

Maybe this means that you have less to worry about?

As a side note - I have tried to work on other projects that read and parse existing configuration, and that was always a nightmare. Systems that take full control and 'dump' the config are definitely a lot
easier to manage.

[ziirish]

I couldn't agree more. Config parsing is a nightmare. But I wanted burp-ui to be as less intrusive as possible, hence this self-imposed constraint.

Anyway, I'll see what I can do to integrate this new form of settings (although they are individual I think showing them as pairs will be more meaningful for users).

[grke]

The feature is now in master.