The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Setup Private Collaborator

Mark | Last updated: Apr 04, 2021 09:43PM UTC

I've been working on this for more days then I'd like to admit. Think I'm just about done but I can't get past this.. It's not able to bind on port 53/TCP Also I don't know where to see details of what the issue is.. i.e.logs. Here's a list of the running startup, configs, and outputs of various commands.. The box is running on Digital Ocean where the DNS is delegated to from Route 53. dig.collaborator.mydomain.net resolves to the correct IP address. I also did a dig +trace collaborator.mydomain.net and it is being resolved by digitalocean in the end. I don't see many threads online about private collaborator troubleshooting. I thought that was curious. Thanks in advance ================================ cat ./startcollaborator.sh java -Xms10m -Xmx200m -XX:GCTimeRatio=19 -jar burpsuite_pro_v2021.3.1.jar --collaborator-server --collaborator-config=coll.config root@lilguy:~# ./startcollaborator.sh 2021-04-04 21:19:56.901 : Using configuration file coll.config 2021-04-04 21:19:57.967 : Listening for SMTP on 143.xxx.xxx.x3:25 2021-04-04 21:19:57.967 : Listening for SMTP on 143.xxx.xxx.x3:587 2021-04-04 21:19:57.963 : Dns service error when binding to 53 java.net.BindException: Address already in use (Bind failed) at java.base/java.net.PlainDatagramSocketImpl.bind0(Native Method) at java.base/java.net.AbstractPlainDatagramSocketImpl.bind(AbstractPlainDatagramSocketImpl.java:131) at java.base/java.net.DatagramSocket.bind(DatagramSocket.java:394) at java.base/java.net.DatagramSocket.<init>(DatagramSocket.java:244) at burp.aic.a(Unknown Source) at burp.aic.run(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) 2021-04-04 21:19:57.972 : Listening for HTTP on 143.xxx.xxx.x3:80 2021-04-04 21:19:57.986 : Listening for DNS on 143.xxx.xxx.x3:53 2021-04-04 21:19:58.190 : Listening for HTTPS on 143.xxx.xxx.x3:443 2021-04-04 21:19:58.191 : Listening for SMTPS on 143.xxx.xxx.x3:465 2021-04-04 21:19:58.459 : Could not start services Exception in thread "main" burp.e8y: Could not start services at burp.fcp.a(Unknown Source) at burp.bnr.a(Unknown Source) at burp.StartBurp.main(Unknown Source) root@lilguy:~# lsof -i:53 │COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME │java 1823 root 15u IPv4 26022 0t0 UDP collaborator.mydomain.net:domain With ./startcollaborator.sh running .. I run the below and get connection refused.. So it appears the TCP port 53 is not able to bind. But from above loof nothing is on 53 except java collaborator. ? root@lilguy:~# nc -vz 143.xxx.xxx.x3 53 │collaborator.mydomain.net [143.xxx.xxx.x3] 53 (domain) : Connection refused root@lilguy:~# netstat -tupl | grep java │tcp 0 0 collaborator:submission 0.0.0.0:* LISTEN 1777/java │tcp 0 0 collaborator.anony:http 0.0.0.0:* LISTEN 1777/java │tcp 0 0 collaborato:submissions 0.0.0.0:* LISTEN 1777/java │tcp 0 0 collaborator.anony:smtp 0.0.0.0:* LISTEN 1777/java │tcp 0 0 collaborator.anon:https 0.0.0.0:* LISTEN 1777/java │udp 0 0 collaborator.ano:domain 0.0.0.0:* 1777/java Below is my collaborator config file. I've replaced the "localAddress" with the public because I wasn't getting anything to bind on the public address.. The Health Check was failing completely. root@lilguy:~# cat coll.config [0/120] { "serverDomain" : "collaborator.mydomain.net", "workerThreads" : 10, "eventCapture": { "localAddress" : ["143.xxx.xxx.x3"], "publicAddress" : "143.xxx.xxx.x3", "http": { "ports" : 80 }, "https": { "ports" : 443 }, "smtp": { "ports" : [25, 587] }, "smtps": { "ports" : 465 }, "ssl": { "certificateFiles" : [ "/usr/local/collaborator/keys/privkey.crt", "/usr/local/collaborator/keys/cert.pem", "/usr/local/collaborator/keys/fullchain.pem", ] } }, "metrics": { "path" : "jnaicmez8", "addressWhitelist" : ["107.xxx.xxx.x"] }, "dns": { "interfaces" : [{ "name": "ns1", "localAddress" : "143.xxx.xxx.x3", "publicAddress" : "143.xxx.xxx.x3" }, { "name" : "ns2", "localAddress" : "143.xxx.xxx.x3", "publicAddress" : "143.xxx.xxx.x3" }], "ports" : 53 }, "logLevel" : "DEBUG" } Health Check: .. Server Location: collaborator.mydomain.net Initiating health check Server address resolution Warning Polling server address resolution Success Polling server connection Success Verify DNS interaction Warning Verify HTTP interaction Warning Verify HTTPS interaction Warning Verify SMTP interaction Warning Verify SMTPS interaction Warning Server version Success

Michelle, PortSwigger Agent | Last updated: Apr 05, 2021 01:11PM UTC

Thanks for your message.

During the Collaborator startup the following is reported:

2021-04-04 21:19:57.963 : Dns service error when binding to 53
java.net.BindException: Address already in use (Bind failed)

Is anything listening on udp port 53 when the Collaborator service is not running? Are the localAddress and publicAddress used for the DNS interfaces the same IP or is there some NAT in place?

If there are any details relating to this that you would rather share directly instead of via the forum, please feel free to email us using support@portswigger.net.

Mark | Last updated: Apr 05, 2021 02:44PM UTC

Thanks for the speedy reply. I'll try and share everything here for everyone's benefit as I don't see many postings for private collaborator. Is anything listening on udp port 53 when the Collaborator service is not running? No there is not Are the localAddress and publicAddress used for the DNS interfaces the same IP or is there some NAT in place? -Correct, the local and public addresses are configured to use the same IP. -There are actually 3 IPs, 2 local and 1 public on the box but as stated I couldn't get anything to work at all putting in the local interfaces. -There is no NAT in place. I'll add one more thing.. the Network firewall is wide open to my address for all ports tcp/udp and icmp and the local firewall is disabled.

Michelle, PortSwigger Agent | Last updated: Apr 06, 2021 02:42PM UTC

Thanks for the update.

If all the IP addresses for the DNS interfaces are the same for both ns1 and ns2, then what's probably happening here is that the DNS is binding to the interfaces successfully for the first DNS interface and then failing for the second one because it's already being used by the first Collaborator DNS interface.

If you remove ns2 from the DNS section in your configuration file, do the services start properly?

Michelle, PortSwigger Agent | Last updated: Apr 06, 2021 02:45PM UTC

If they do start properly with just one interface, but you need to have ns2 configured then can the localAddress for ns2 be bound to a different local interface?

Mark | Last updated: Apr 06, 2021 07:36PM UTC

Great suggestion :) I think your correct in what's going on. Yes removing ns2 the services started w/o error. I tried your suggestions with the local interfaces but not getting around the health check errors. Also tried with ns1 local&public configured with the only the public AND ns2 local&public configured with each different local interface. ========================================================================= "name": "ns1", "localAddress" : "143.xxx.xxx.x3", "publicAddress" : "143.xxx.xxx.x3" }, { "name" : "ns2", "localAddress" : "10.xx.xx.5", < I tested with each local interface here, same result "publicAddress" : "143.xxx.xxx.x3" 2021-04-06 19:00:56.392 : Using configuration file coll.config 2021-04-06 19:00:57.420 : Listening for SMTP on 143.xxx.xxx.x3:25 2021-04-06 19:00:57.420 : Listening for SMTP on 143.xxx.xxx.x3:587 2021-04-06 19:00:57.427 : Listening for DNS on 10.xx.xx.5:53 2021-04-06 19:00:57.435 : Listening for HTTP on 143.xxx.xxx.x3:80 2021-04-06 19:00:57.436 : Listening for DNS on 143.xxx.xxx.x3:53 2021-04-06 19:00:57.641 : Listening for HTTPS on 143.xxx.xxx.x3:443 2021-04-06 19:00:57.642 : Listening for SMTPS on 143.xxx.xxx.x3:465 2021-04-06 19:01:08.927 : Received HTTPS polling request from [107.xxx.xxx.9] 2021-04-06 19:01:09.172 : Received HTTPS polling request from [107.xxx.xxx.9] ================================================================================ "dns": { "interfaces" : [{ "name": "ns1", "localAddress" : "10.xxx.xxx.2", "publicAddress" : "143.xxx.xxx.x3" }, { "name" : "ns2", "localAddress" : "10.xx.xx.5", "publicAddress" : "143.xxx.xxx.x3" }], 2021-04-06 19:03:47.751 : Using configuration file coll.config 2021-04-06 19:03:48.977 : Listening for SMTP on 143.xxx.xxx.x3:25 2021-04-06 19:03:48.977 : Listening for SMTP on 143.xxx.xxx.x3:587 2021-04-06 19:03:48.977 : Listening for HTTP on 143.xxx.xxx.x3:80 2021-04-06 19:03:48.984 : Listening for DNS on 10.xxx.xxx.2:53 2021-04-06 19:03:48.991 : Listening for DNS on 10.xx.xx.5:53 2021-04-06 19:03:49.200 : Listening for SMTPS on 143.xxx.xxx.x3:465 2021-04-06 19:03:49.203 : Listening for HTTPS on 143.xxx.xxx.x3:443 Server address resolution Warning Polling server address resolution Success Polling server connection Success Verify DNS interaction Warning Verify HTTP interaction Warning Verify HTTPS interaction Warning Verify SMTP interaction Warning Verify SMTPS interaction Warning Server version Success

Michelle, PortSwigger Agent | Last updated: Apr 07, 2021 07:40AM UTC

It's good to hear that things are getting a bit further now. If you're still seeing issues with the health check then the next stage is to take a closer look at the DNS delegation set up so all requests for your domain are sent to the Collaborator Server.

Can you tell me a bit more about what you've set up so far, please?
(If you do need to send any examples that show your actual domain name, feel free to email those over marked for my attention and I'm happy to reply back on this thread)

Mark | Last updated: Apr 07, 2021 02:40PM UTC

Just sent it over.. thank you

Michelle, PortSwigger Agent | Last updated: Apr 08, 2021 11:43AM UTC

Thanks for sending those screenshots :) When you're setting up the DNS records, for each nameserver in your collaborator config you need an A or AAAA entry as appropriate (which you seem to have in place). You also need an NS record for your domain that points to the FQDN of one of your nameservers, so any queries for foo.collaborator.mydomain.net get directed to your private collaborator server. From the screenshots, I think it's this second one that could be causing the problems you're seeing, as your NS record seems to be currently pointing to a different nameserver. I hope this helps, let me know how you get on and if you have any questions.

Mark | Last updated: Apr 08, 2021 02:58PM UTC

Thanks for that analysis :) Yeah I actually had it configured that way originally and didn't have any luck.. glad you came up with that conclusion though. I've put it back adding ns1 and 2 for the burp instance and removed ns records for DO. Sadly same result :( Sent you screen shots again. I also did a dig trace "dig +trace ns1...the domain " and it looks like it should so I'm perplexed why it's not working. I wish we could see more behind the scenes info...logs as to whats going on.

Michelle, PortSwigger Agent | Last updated: Apr 08, 2021 03:14PM UTC

Thanks for the new screenshots. Sorry, we might have got our wires slightly crossed before. Your NS record for collaborator.mydomain.net needs to direct to ns1.collaborator.mydomain.net / ns2.collaborator.mydomain.net rather than DO. I hope that makes sense, if not I'll reply via email and pop a summary on here.

Mark | Last updated: Apr 08, 2021 04:53PM UTC

Sent you an updated screen shot.. same result so far.

Mark | Last updated: Apr 08, 2021 06:07PM UTC

Sent you a tcpdump Should have mentioned in the email, I ran that while performing a Health Check. Seems like it's looking for a PTR record?

Michelle, PortSwigger Agent | Last updated: Apr 12, 2021 01:38PM UTC

Hi I've just replied to your email to check a couple of details with you. If we need to make any changes I'll keep the posts up-to-date here so any resolutions can be shared.

Mark | Last updated: Apr 16, 2021 03:57PM UTC