Jump to content

C2 behind reverse Proxy Web SSH Session not working


Le0n
 Share

Recommended Posts

Hello, I am very desperate right now. I've been trying in vain for days now to get C2 with all functions running behind a reverse Proxy.

Devices are connecting, but i have two issues that i can't solve. I think these are Bugs. And I think both are interrelated.

I have testet this in two scenarios:
1. I have the reverse Proxy and C2 Server on the same machine.
2. Device reverse Proxy and C2 Server on different devices.

In the process I have found out that if C2 is running behind a reverse Proxy the external Device IP is always the IP from the reverse Proxy Server.

For instance if I have the first scenario where both are on the same device then the external IP is always 127.0.0.1
If C2 is on another device the external IP is the private IP from my reverse Proxy Server.

Now the second problem. I think this exists only because of the other one.
When i try to Start an SSH Session to device (C2 based) than that does not work. 
Either it loads forever and nothing happens or the black windows opens and print out "Disconnected"

When I start C2 without -reverseProxy and -reverseProxyPort flag, then download device.config again and put on the device everything works as it should. external IP is right and SSH Session works too. So a Port configuration problem or something is excluded.

When i start C2 in Debug Mode there are many errors.

Eventually I am to stupid, but can anyone help me please?

Error Logs:
 

Log Scenario 2: with Disconnected error in GUI

debug	| 2021-12-30 19:12:55 New User Session: 1 409aa6
apilog	| 2021-12-30 19:12:55 leon@192.168.178.171:35952 GET /api/sites/1/devices
apilog	| 2021-12-30 19:12:56 leon@192.168.178.171:35954 GET /api/sites/1/stats
apilog	| 2021-12-30 19:12:56 leon@192.168.178.171:35958 GET /api/status
apilog	| 2021-12-30 19:12:56 leon@192.168.178.171:35960 GET /api/sites/1/stats
apilog	| 2021-12-30 19:12:58 leon@192.168.178.171:35988 GET /api/sites/1/devices/1
apilog	| 2021-12-30 19:12:58 leon@192.168.178.171:35990 GET /api/sites/1/devices/1/status
apilog	| 2021-12-30 19:12:58 leon@192.168.178.171:35992 GET /api/sites/1/stats/devices/1




apilog	| 2021-12-30 19:13:03 leon@192.168.178.171:36012 GET /api/sites/1/devices/1
apilog	| 2021-12-30 19:13:03 leon@192.168.178.171:36016 GET /api/sites/1/devices/1/notes
apilog	| 2021-12-30 19:13:03 leon@192.168.178.171:36014 GET /api/sites/1/devices/1/status
apilog	| 2021-12-30 19:13:03 leon@192.168.178.171:36020 GET /api/sites/1/stats/devices/1
apilog	| 2021-12-30 19:13:05 leon@192.168.178.171:36022 GET /api/sites/1/devices/1
apilog	| 2021-12-30 19:13:05 leon@192.168.178.171:36024 GET /api/sites/1/devices/1/crocconfig
apilog	| 2021-12-30 19:13:05 leon@192.168.178.171:36026 GET /api/sites/1/devices/1/keystrokes/history
apilog	| 2021-12-30 19:13:05 leon@192.168.178.171:36028 GET /api/sites/1/devices/1/deviceloot
apilog	| 2021-12-30 19:13:05 leon@192.168.178.171:36030 GET /api/sites/1/devices/1/matchpayloads
apilog	| 2021-12-30 19:13:05 leon@192.168.178.171:36036 GET /api/sites/1/stats/devices/1
apilog	| 2021-12-30 19:13:05 leon@192.168.178.171:36034 GET /api/sites/1/devices/1/status
apilog	| 2021-12-30 19:13:07 leon@192.168.178.171:36046 GET /api/sites/1/devices/1
apilog	| 2021-12-30 19:13:07 leon@192.168.178.171:36048 GET /api/sites/1/devices/1/crocconfig
apilog	| 2021-12-30 19:13:07 leon@192.168.178.171:36050 GET /api/sites/1/devices/1/keystrokes/history
apilog	| 2021-12-30 19:13:07 leon@192.168.178.171:36052 GET /api/sites/1/devices/1/matchpayloads
apilog	| 2021-12-30 19:13:07 leon@192.168.178.171:36054 GET /api/sites/1/devices/1/deviceloot
apilog	| 2021-12-30 19:13:07 leon@192.168.178.171:36056 GET /api/sites/1/devices/1/status
apilog	| 2021-12-30 19:13:07 leon@192.168.178.171:36060 GET /api/sites/1/stats/devices/1
apilog	| 2021-12-30 19:13:08 leon@192.168.178.171:36062 GET /api/sites/1/devices/1
apilog	| 2021-12-30 19:13:08 leon@192.168.178.171:36064 GET /api/sites/1/devices/1/status
apilog	| 2021-12-30 19:13:08 leon@192.168.178.171:36066 GET /api/sites/1/devices/1/notes
apilog	| 2021-12-30 19:13:08 leon@192.168.178.171:36070 GET /api/sites/1/stats/devices/1
apilog	| 2021-12-30 19:13:08 leon@192.168.178.171:36072 GET /api/sites/1/devices
apilog	| 2021-12-30 19:13:08 leon@192.168.178.171:36074 GET /api/sites/1/stats
apilog	| 2021-12-30 19:13:08 leon@192.168.178.171:36076 GET /api/sites/1/stats
apilog	| 2021-12-30 19:13:10 leon@192.168.178.171:36092 GET /api/sites/1/devices/1
apilog	| 2021-12-30 19:13:10 leon@192.168.178.171:36098 GET /api/sites/1/stats/devices/1
apilog	| 2021-12-30 19:13:10 leon@192.168.178.171:36096 GET /api/sites/1/devices/1/status
apilog	| 2021-12-30 19:13:11 leon@192.168.178.171:36100 GET /api/sites/1/devices/1
apilog	| 2021-12-30 19:13:11 leon@192.168.178.171:36102 GET /api/sites/1/devices/1/crocconfig
apilog	| 2021-12-30 19:13:11 leon@192.168.178.171:36104 GET /api/sites/1/devices/1/keystrokes/history
apilog	| 2021-12-30 19:13:11 leon@192.168.178.171:36106 GET /api/sites/1/devices/1/matchpayloads
apilog	| 2021-12-30 19:13:11 leon@192.168.178.171:36108 GET /api/sites/1/devices/1/deviceloot
log	| 2021-12-30 19:13:11 Device 'Key Croc' has started up
debug	| 2021-12-30 19:13:11 DB AddActionToDevice devid: 1, type: 16
debug	| 2021-12-30 19:13:11 DB AddActionToDevice devid: 1, type: 21
debug	| 2021-12-30 19:13:11 DB AddActionToDevice devid: 1, type: 24
debug	| 2021-12-30 19:13:11 Device 1 checking in for actions
apilog	| 2021-12-30 19:13:11 leon@192.168.178.171:36114 GET /api/sites/1/devices/1
apilog	| 2021-12-30 19:13:11 leon@192.168.178.171:36116 GET /api/server/status
apilog	| 2021-12-30 19:13:11 leon@192.168.178.171:36118 GET /api/sites/1/devices/1/loot
apilog	| 2021-12-30 19:13:13 leon@192.168.178.171:36126 GET /api/sites/1/devices/1/status
apilog	| 2021-12-30 19:13:13 leon@192.168.178.171:36130 GET /api/sites/1/stats/devices/1
debug	| 2021-12-30 19:13:13 Device 'Key Croc' Completed Change Sync
debug	| 2021-12-30 19:13:13 DB DeleteActionFromDevice devid: 1, actionid: 10
debug	| 2021-12-30 19:13:13 Device 'Key Croc' Completed Change Sync
debug	| 2021-12-30 19:13:13 DB DeleteActionFromDevice devid: 1, actionid: 11
debug	| 2021-12-30 19:13:13 Device 'Key Croc' Completed Change Sync
debug	| 2021-12-30 19:13:13 DB DeleteActionFromDevice devid: 1, actionid: 12
apilog	| 2021-12-30 19:13:14 leon@192.168.178.171:36134 GET /api/sites/1/devices
apilog	| 2021-12-30 19:13:14 leon@192.168.178.171:36136 GET /api/sites/1/stats
apilog	| 2021-12-30 19:13:14 leon@192.168.178.171:36140 GET /api/sites/1/stats
apilog	| 2021-12-30 19:13:15 leon@192.168.178.171:36150 GET /api/sites/1/devices/1
apilog	| 2021-12-30 19:13:15 leon@192.168.178.171:36154 GET /api/sites/1/stats/devices/1
apilog	| 2021-12-30 19:13:15 leon@192.168.178.171:36152 GET /api/sites/1/devices/1/status
apilog	| 2021-12-30 19:13:17 leon@192.168.178.171:36158 GET /api/sites/1/devices/1
apilog	| 2021-12-30 19:13:17 leon@192.168.178.171:36160 GET /api/sites/1/devices/1/ssh/status
apilog	| 2021-12-30 19:13:18 leon@192.168.178.171:36170 POST /api/sites/1/devices/1/ssh/start
debug	| 2021-12-30 19:13:18 DB AddActionToDevice devid: 1, type: 17
apilog	| 2021-12-30 19:13:18 leon@192.168.178.171:36172 GET /api/sites/1/devices/1/ssh/status
debug	| 2021-12-30 19:13:18 Device 1 checking in for actions
apilog	| 2021-12-30 19:13:20 leon@192.168.178.171:36176 GET /api/sites/1/devices/1/ssh/status
apilog	| 2021-12-30 19:13:20 leon@192.168.178.171:36178 GET /api/sites/1/devices/1
debug	| 2021-12-30 19:13:21 Device 'Key Croc' Completed Change Sync
debug	| 2021-12-30 19:13:21 DB DeleteActionFromDevice devid: 1, actionid: 13
debug	| 2021-12-30 19:13:21 Database update error: bucket not found
log	| 2021-12-30 19:13:21 Internal error: bucket not found
apilog	| 2021-12-30 19:13:22 leon@192.168.178.171:36188 GET /api/sites/1/devices/1/ssh/status
debug	| 2021-12-30 19:13:22 New User Session: 1
apilog	| 2021-12-30 19:13:22 leon@192.168.178.171:36190 GET /api/sites/1/devices/1/ssh/ws
log	| 2021-12-30 19:13:22 leon@192.168.178.171:36190 has requested an SSH session for Device Key Croc @ Home
apilog	| 2021-12-30 19:13:22 httperror 192.168.178.171:36190 error upgrading websocket
2021/12/30 19:13:22 http: superfluous response.WriteHeader call from github.com/hak5/cc-server/api/web.(*Api).httperror (utils.go:58)
apilog	| 2021-12-30 19:13:25 leon@192.168.178.171:36192 GET /api/sites/1/devices/1
debug	| 2021-12-30 19:13:26 Device 1 checking in for actions
debug	| 2021-12-30 19:13:27 Device 'Key Croc' Completed Change Sync
debug	| 2021-12-30 19:13:27 DB DeleteActionFromDevice devid: 1, actionid: 13
debug	| 2021-12-30 19:13:27 Device 'Key Croc' Completed Change Sync
debug	| 2021-12-30 19:13:27 DB DeleteActionFromDevice devid: 1, actionid: 13
debug	| 2021-12-30 19:13:27 Database update error: bucket not found
log	| 2021-12-30 19:13:27 Internal error: bucket not found

This is one of the more important errors i get this error too when not in Debugging mode:

2021/12/30 19:13:22 http: superfluous response.WriteHeader call from github.com/hak5/cc-server/api/web.(*Api).httperror (utils.go:58)

Log Scenario 1:

debug	| 2021-12-30 19:39:50 Serving Login / Setup
log	| 2021-12-30 19:39:55 User leon has logged in from 127.0.0.1:43978
apilog	| 2021-12-30 19:39:55 User leon has logged in from 127.0.0.1:43978
debug	| 2021-12-30 19:39:55 New User Session: 1 b3847f
apilog	| 2021-12-30 19:39:56 leon@127.0.0.1:43990 GET /api/sites/1/devices
apilog	| 2021-12-30 19:39:56 leon@127.0.0.1:43992 GET /api/sites/1/stats
apilog	| 2021-12-30 19:39:56 leon@127.0.0.1:43996 GET /api/status
apilog	| 2021-12-30 19:39:56 leon@127.0.0.1:43998 GET /api/sites/1/stats
apilog	| 2021-12-30 19:39:57 leon@127.0.0.1:44004 GET /api/sites/1/devices/1
apilog	| 2021-12-30 19:39:58 leon@127.0.0.1:44016 GET /api/sites/1/stats/devices/1
apilog	| 2021-12-30 19:39:58 leon@127.0.0.1:44018 GET /api/sites/1/devices/1/status
apilog	| 2021-12-30 19:39:59 leon@127.0.0.1:44038 GET /api/sites/1/devices/1
apilog	| 2021-12-30 19:39:59 leon@127.0.0.1:44040 GET /api/sites/1/devices/1/ssh/status
debug	| 2021-12-30 19:39:59 New User Session: 1
apilog	| 2021-12-30 19:39:59 leon@127.0.0.1:44046 GET /api/sites/1/devices/1/ssh/ws
log	| 2021-12-30 19:39:59 leon@127.0.0.1:44046 has requested an SSH session for Device Key Croc @ default
apilog	| 2021-12-30 19:39:59 httperror 127.0.0.1:44046 error upgrading websocket
2021/12/30 19:39:59 http: superfluous response.WriteHeader call from github.com/hak5/cc-server/api/web.(*Api).httperror (utils.go:58)
apilog	| 2021-12-30 19:40:02 leon@127.0.0.1:44052 GET /api/sites/1/devices/1
log	| 2021-12-30 19:40:03 Device 'Key Croc' has started up
debug	| 2021-12-30 19:40:03 DB AddActionToDevice devid: 1, type: 16
debug	| 2021-12-30 19:40:03 DB AddActionToDevice devid: 1, type: 21
debug	| 2021-12-30 19:40:03 DB AddActionToDevice devid: 1, type: 24
debug	| 2021-12-30 19:40:03 Device 1 checking in for actions
debug	| 2021-12-30 19:40:04 Device 'Key Croc' Completed Change Sync
debug	| 2021-12-30 19:40:04 DB DeleteActionFromDevice devid: 1, actionid: 14
debug	| 2021-12-30 19:40:04 Device 'Key Croc' Completed Change Sync
debug	| 2021-12-30 19:40:04 DB DeleteActionFromDevice devid: 1, actionid: 15
debug	| 2021-12-30 19:40:05 Device 'Key Croc' Completed Change Sync
debug	| 2021-12-30 19:40:05 DB DeleteActionFromDevice devid: 1, actionid: 16
apilog	| 2021-12-30 19:40:07 leon@127.0.0.1:44068 GET /api/sites/1/devices/1

PS: I have also tried deleting the Database file and setup all thing from zero but same error on both devices.

C2: start Parameters: 

./c2-3.1.2_armv7_linux -hostname c2.mydomain.de -reverseProxy -reverseProxyPort 80 -db /var/cloudc2/c2.db


Here the Screenshots:

Photo scenario 1 
Photo scenario 2 - 

Photo error


 

Link to comment
Share on other sites

12 minutes ago, dark_pyrro said:

Perhaps if you start yet another thread (the fourth), you might get some help...

Oh sh*t i don’t want to post it more than one time. I am new here and only (after submitting the post) clicked on page back on my web browser an then I where back in edit mode. I thought I can change some things and then submit again and it will be edited. How can I delete the others ?

Link to comment
Share on other sites

On 12/30/2021 at 9:13 PM, dark_pyrro said:

What's your level of experience when it comes to setting up reverse proxy servers? What reverse proxy server are you using? In what way is it configured?

This is my first reverse Proxy. It is an nginx reverse Proxy. I found out some new things. The most important one. The two problems are not interdependent. I startet C2 normal without any reverse Proxy or other settings. Only with the command 

./c2-3.1.2_armv7_linux -hostname c2.mydomain.de

So C2 started as normal on Port 8080. I forwarded port 8080 to give access to the devices. Then i reinstalled the device.conf. So the device is connecting to Port 8080 and 2022 for ssh. When i now open c2 on c2.mydomain.de:8080 and start an ssh session everything works fine. But when i open c2 via the reverse Proxy on c2.mydomain.de (this connects to the reverse Proxy on Port 80 and then forwarded to Port 8080 ) the ssh Session does not work. Then i get the "disconnected" error and again this error on the terminal:

http: superfluous response.WriteHeader call from github.com/hak5/cc-server/api/web.(*Api).httperror (utils.go:58)

For the IP Problem i found out how to forward the real IP from the connecting device via reverse Proxy to cloud C2

my Proxy Config is the following:
 

# This hs nothing to do with C2
server {
        listen 80;
	server_name  mydomain.de www.mydomain.de;

        location / {
                   # proxy_pass http://127.0.0.1:8000;
                    return 301 https://mydomain.de$request_uri; # Redirect http to https
  }
}

server {
        listen 443;
	server_name  mydomain.de www.mydomain.de;

	ssl_certificate           /etc/letsencrypt/live/mydomain.de/fullchain.pem;
	ssl_certificate_key       /etc/letsencrypt/live/mydomain.de/privkey.pem;
	ssl on;
	ssl_session_cache  builtin:1000  shared:SSL:10m;
	ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
	ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
	ssl_prefer_server_ciphers on;


	access_log /var/log/nginx/reverse-access.log;
        error_log /var/log/nginx/reverse-error.log;

        location / {
                    proxy_pass https://127.0.0.1:8443; # encrypted traffic from Proxy to Webserver
                    #proxy_pass http://127.0.0.1:8000; # unencrypted traffic from Proxy to Webserver
  }
}

server {
        listen 80;
	server_name  c2.mydomain.de;

        access_log /var/log/nginx/reverse-access.log;
        error_log /var/log/nginx/reverse-error.log;

# Here i testet some things because i think it is an header problem or something
	#proxy_buffering off;
	ignore_invalid_headers off;
	#proxy_busy_buffers_size   512k;
 	#proxy_buffers   4 512k;
 	#proxy_buffer_size   256k;

        location / {
                    proxy_pass http://127.0.0.1:8080;
                
					# This is for the device IP on C2 but disabled to fix first the other error
                    #proxy_set_header Host $host;
    		   		#proxy_set_header X-Real-IP $remote_addr;
    		   		#proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

		    		#real_ip_header X-Real-IP;
                    #proxy_redirect off;
  }
}

# Only for Browser traffic
server {
        listen 443;
	server_name  c2.mydomain.de;


	ssl_certificate           /etc/letsencrypt/live/c2.mydomain.de/fullchain.pem;
	ssl_certificate_key       /etc/letsencrypt/live/c2.mydomain.de/privkey.pem;
	ssl on;
	ssl_session_cache  builtin:1000  shared:SSL:10m;
	ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
	ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
	ssl_prefer_server_ciphers on;


	access_log /var/log/nginx/reverse-access.log;
        error_log /var/log/nginx/reverse-error.log;

        location / {
                    proxy_pass http://127.0.0.1:8080;

                    #proxy_set_header Host $host;
    		    	#proxy_set_header X-Real-IP $remote_addr;
    		    	#proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

		    		#real_ip_header X-Real-IP;
                   	#proxy_redirect off;
  }
}

 

Link to comment
Share on other sites

OK, so the only remaining problem you have now is to get SSH to work from the C2 web GUI back to the Hak5 devices? I set up a quick test network with an Nginx reverse proxy (without encrypted traffic and Nginx and the C2 server on separate physical devices) and it works in the way as you describe. No problems to get the Hak5 devices to connect via the Nginx server but web GUI ssh sessions from the C2 server back to the devices is not working (just like you have reported).

From the Nginx config file, it looks like you are using 443/https but that it terminates in the Nginx server and then it goes unencrypted to the C2 server "internally" behind the reverse proxy (since you specified "location" to an 8080 based resource). Are you using the reverseProxy parameter only or the reverseProxyPort as well when starting the C2 server? In any way, I think it would be a good idea to disable the use of https until the basic functionality has been solved, it will just add an extra layer of complexity that probably is making it more difficult to troubleshoot the scenario.

Have you tried using stream blocks in the config file and also perhaps the module "ngx_stream_ssl_module" (and/or "ngx_stream_ssl_preread_module")?

Not that it might solve any problems, but it is also possible to try other reverse proxy solutions like Apache or HAProxy and see if it makes any difference. It should work using Nginx though since the basics should be the same regardless of what reverse proxy that is being used.

I should add as well that port 2022 is vital for the ssh session. I added a LAN Turtle now to my lab environment that is set up with a C2 server and an Nginx reverse proxy (mentioned above) and initiated an ssh session to the Turtle from the C2 web GUI and also had a local ssh session directly on the Turtle at the same time and kept on executing ps to get the processes running. Just before getting the "Disconnected" message in the C2 web GUI, a process appeared on the Turtle that was trying to call back to my C2 server (or the Nginx server really) using port 2022. This doesn't seem to change even if using the reverseProxyPort parameter when starting the C2 server, so the callbacks for ssh sessions always uses port 2022. This can also be verified when looking into the device.config file. The port that is specified using the reverseProxyPort parameter changes in the file, but not 2022 that is in the very end of the device.config file.

And, when finding the above process, I searched for C2TERM (that was part of the process) here on the forums and it has indeed been discussed before. Maybe it will sort out your issues.

 

Edited by dark_pyrro
Link to comment
Share on other sites

On 1/3/2022 at 11:25 AM, dark_pyrro said:

OK, so the only remaining problem you have now is to get SSH to work from the C2 web GUI back to the Hak5 devices? I set up a quick test network with an Nginx reverse proxy (without encrypted traffic and Nginx and the C2 server on separate physical devices) and it works in the way as you describe. No problems to get the Hak5 devices to connect via the Nginx server but web GUI ssh sessions from the C2 server back to the devices is not working (just like you have reported).

From the Nginx config file, it looks like you are using 443/https but that it terminates in the Nginx server and then it goes unencrypted to the C2 server "internally" behind the reverse proxy (since you specified "location" to an 8080 based resource). Are you using the reverseProxy parameter only or the reverseProxyPort as well when starting the C2 server? In any way, I think it would be a good idea to disable the use of https until the basic functionality has been solved, it will just add an extra layer of complexity that probably is making it more difficult to troubleshoot the scenario.

Have you tried using stream blocks in the config file and also perhaps the module "ngx_stream_ssl_module" (and/or "ngx_stream_ssl_preread_module")?

Not that it might solve any problems, but it is also possible to try other reverse proxy solutions like Apache or HAProxy and see if it makes any difference. It should work using Nginx though since the basics should be the same regardless of what reverse proxy that is being used.

I should add as well that port 2022 is vital for the ssh session. I added a LAN Turtle now to my lab environment that is set up with a C2 server and an Nginx reverse proxy (mentioned above) and initiated an ssh session to the Turtle from the C2 web GUI and also had a local ssh session directly on the Turtle at the same time and kept on executing ps to get the processes running. Just before getting the "Disconnected" message in the C2 web GUI, a process appeared on the Turtle that was trying to call back to my C2 server (or the Nginx server really) using port 2022. This doesn't seem to change even if using the reverseProxyPort parameter when starting the C2 server, so the callbacks for ssh sessions always uses port 2022. This can also be verified when looking into the device.config file. The port that is specified using the reverseProxyPort parameter changes in the file, but not 2022 that is in the very end of the device.config file.

And, when finding the above process, I searched for C2TERM (that was part of the process) here on the forums and it has indeed been discussed before. Maybe it will sort out your issues.

 

Amazing Work! I changed my proxy config and now it works!!I can open the Browser SSH Session!  I am so happy! 😃
And the funny thing. After i change my proxy config and testet a little bit i saw that the Uptime in C2 is counting up. This has never been the case before. It was always stuck at 2 or 3 Seconds Uptime. I thought this was a bug or something. Also in debug mode there where no database errors. I have tried to fix these before:
 

debug	| 2022-01-04 14:07:42 Device 'K1' Completed Change Sync
debug	| 2022-01-04 14:07:42 DB DeleteActionFromDevice devid: 2, actionid: 6
debug	| 2022-01-04 14:07:47 Device 2 checking in for actions
debug	| 2022-01-04 14:07:48 Database update error: bucket not found
log	| 2022-01-04 14:07:48 Internal error: bucket not found
debug	| 2022-01-04 14:07:53 Device 2 checking in for actions
debug	| 2022-01-04 14:07:55 Database update error: bucket not found

Ok. Everything was fine and working, and i thought it might be a good idea to reflash my Key Croc wich i used to test all these things because it is the easiest one.
After reflash I copied back the device.config and rebooted the Croc. Sadly now the Uptime is stuck again at 2 seconds. I found this post where someone had the same issue:

But there is no solution for the problem. I tried many different things. Deleted c2.db and started from scratch, first all without the reverse Proxy so normal C2 with Port 8080, then with proxy. Then I tried to reproduce what i have done earlier to get proxy things working, I also tried C2 on a completely different device - with and without proxy but nothing. Uptime Is still stuck and I get these error on cli. I wonder what happen to my croc or C2 that it spontaneously startet to count the Uptime and then spontaneously stopped it.

Don't tested other devices yet but I will do that later!

I then tested to get things running over https: But this is not so important i only wanted to test if it is possible if not it is not a problem. For this I found a post. I tried the solution with an other nginx config but that did not work for me. No Problem. But if found a very interesting thing in the post that i tested and it worked. I tried to google on how it works but i have found nothing. I would only be interested how it works.
It's about to let Hak5 devices speak over Port 80 over nginx to C2 and redirect everything else (i.e. browser traffic and to on) to Port 443. And its very interesting. 
How can the proxy know that it is an Hak5 device that is calling home only from the config: 
 

 # Requests by Hak5 devices remain on plain HTTP.
    location /dapi {
        proxy_pass http://localhost:8080;
    }

    # All other requests are redirected to HTTPS.
    location / {
        return 301 https://$server_name$request_uri;
    }

What does this "location /dapi" mean I didn't found anything around the internet. Did you eventually know that? I found it coincidentally but last week I tried to achieve just that. And know i wonder how it works. Here is the original comment:

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...