Network access control at the burp level [feature request]

[do11]

Currently, if I want to allow only trusted servers to be able to connect to a burp server I should use firewall. Which is different entity and also requires root privileges.

If we don't limit access to a burp port anybody can establish full ssl connection, which is additional exposure to possible attacks on the server, openssl and burp itself (which put danger on backups). Openssl library is not too trusted to be security perfect and bug-less.

I propose to have per client allow directive with cidr(s) and hostnames which is allowed to connect to burp server and checked just after accept and before libssl code is run. This way we could just add additional allow option per client and not touch firewall also reducing openssl exposure.

Also this way there could be established link between cname and allowed IPs,

(Yes, probably, all configs in clientconfdir should be read on every connection.)

[grke]

Hello,

I am not sure about this idea. It seems to be a firewall's job.

[do11]

Configuring firewall could be good as additional measure. Just to rely on firewall is error prone and not handy. It's required root to configure firewall; user may forget to remove IP of some client from firewall when removing/disabling client in clientconfdir; with burp controlled allow option we can assocuate certificate with allowed IPs, (in firewall scenario cert could be stolen and accessed from other box in allowed network), also, in firewall people tend to add whole network instead of just backed up boxes which is additional exposure. I see there is so many benefits of having acl in burp.

In firewall we could permit whole intranet/dmz and in clientconfdir we could add per-client hostnames (which is easy to understand and right place to configure, and would not burden user with security). People tend to avoid security when it burdens too much.

[jirib]

Usually backup service is available in separate VLANs. So, what is your use case? Do you run burp server on publicly accessible interface? If so, then it's bad design choice.

Anyway, IIUC you are mostly worried about untrusted connection to try SSL handshake and because you don't trust OpenSSL. Am I right?

The first is similar to having OpenSSH publicly accessible - if we assume you have your burp server on public interface. There are various techniques to minimalize "spammers" by blocking them temporarily via IP, anyway, burp server should not be on public interface.

The latter, OpenSSL, maybe you should switch to better OS :) burp could use LibreSSL but it's not available by default on various Linux distros and it could user privilege separated key handling like OpenBSD daemons do, see https://undeadly.org/cgi?action=article;sid=20140430155940

[do11]

@jirib Very rarely backup is run on separate VLAN (or even on separate physical interface). Also, what is 'publicly accessible' interface? You live not alone in intranet and there could be all sort of people, co-workers with different level of security. clients and sub-clients. They all may benefit from backup service. So, you can not put everybody in separate VLAN, And, if you do put everybody in separate VLAN then everybody have access to your VLAN, thus making it as good as public interface, and making your single burp there (even if all VLANs are completely different for each box) exposed equally to all of them.

In such scenario making firewall rule is equivalent to VLANs. You still have network granularity in your acl. I ask for feature that would allow limiting access by single IP to single client granularity.

Also VLAN [not-]solution still requires root privileges.

[jirib]

@do11 I'm sorry, I only worked as sysadmin in well organized env - doing sysadmin work for world top enterprises like banks, automobile industry where we had separate vlans for backup/tftp, service, and admin. Having backup on separate interface (thus [V]LAN) is good because backup needs to be fast and service your server provides should not be impacted from network usage. "Very rarely..." doesn't mean anything, majority or even 99% of people doesn't mean they are right.

[do11]

@jirib I never said they are right or wrong, or that using vlan or lan is right, or wrong, or better, or worse, or bad, or correct, that would be value judgment, which would be tightly linked to particular value system, which are very diverse. I also doubt that burp is enterprise solution. What is certain, is that backups are advisable.

[dmitry-sinina]

I also would like to have IP ACLs on BURP level. @grke will you approve proper PR with this feature or you don't want to have this feature?

[jirib]

I read little bit Zero Trust Network book and whole point of trust based on IPs seems to be overrated and it has become complicated in cloud world where instances come and disappear. The point of the argumentation in the book is that IP is not enough as criterion for trust.

See https://www.cipherdyne.org/fwknop/ which implementes Sinle packet authorization which seems to be better than trust based only on an IP, and which can "open" a service for your client.

[dmitry-sinina]

I don't understand how it related to our case. BURP are using TLS certificates to perform client authentication, so this is not about trust based on IP. This is about limiting network access to burp socket to reduce authentication implementations(libssl) exposure and about limiting access per client(which is not possible on firewall level, since firewall have no information about clients and TLS auth results).

[grke]

Hello @dmitry-sinina , I am very happy to review a PR for this feature. Thank you for your consideration!

[piligrim773]

https://github.com/grke/burp/pull/876