Hi Members,
Last time I have successfully implemented and the client was enrolled with openziti.
But I am facing some issue, as the server (192.x.x.1) is still able to be accessed even without using accessing “testpage.ziti”.
So how can I stop accessing using 192.x.x.1 and only it can be accessed via “testpage.ziti”.
What I am missing?
Thank you
If you’re testing on the same network, that could make sense. Are you certain the test page is not addressable from the client machine?
Also, how did you install the client? Could it have restarted without you knowing it?
Those are the only two situations I can think of right now that make sense as to why you’re seeing this
Thank you for your reply
I followed the procedure from this url
First I created identity for the server (as device)
Copied jwt to the server (192.x.x.1) and started the service
Added the service in identity (for testclient that is already created and added the jwt for testclient). And installed the Ziti Edge Desktop and enrolled it via testclient.jwt.
Client able to access via testpage.ziti but also able to access via 192.x.x.1
PS: Service output
systemctl status ziti-edge-tunnel.service
Loaded: loaded (/etc/systemd/system/ziti-edge-tunnel.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2023-08-13 13:30:50 UTC; 4min 4s ago
Process: 14150 ExecStartPre=/opt/openziti/bin/ziti-edge-tunnel.sh (code=exited, status=0/SUCCESS)
Main PID: 14151 (ziti-edge-tunne)
Tasks: 5 (limit: 3397)
Memory: 5.3M
CPU: 1.074s
CGroup: /system.slice/ziti-edge-tunnel.service
└─14151 /opt/openziti/bin/ziti-edge-tunnel run --verbose=2 --dns-ip-range=100.x.x.1/10 --identity-dir=/opt/openziti/etc/identities
Aug 13 13:30:50 ub22-min2 systemd[1]: Starting Ziti Edge Tunnel...
Aug 13 13:30:50 ub22-min2 ziti-edge-tunnel.sh[14150]: NOTICE: no new JWT files in /opt/openziti/etc/identities/*.jwt
Aug 13 13:30:50 ub22-min2 systemd[1]: Started Ziti Edge Tunnel.
Aug 13 13:30:50 ub22-min2 ziti-edge-tunnel[14151]: (14151)[ 0.000] WARN ziti-edge-tunnel:ziti-edge-tunnel.c:1665 make_socket_path() failed to set ownership of /tmp/.ziti to 999:999: Operation not permitted (errno=1)
Aug 13 13:30:50 ub22-min2 ziti-edge-tunnel[14151]: (14151)[ 0.000] WARN ziti-edge-tunnel:ziti-edge-tunnel.c:1709 run_tunneler_loop() One or more socket servers did not properly start.
root@ub22-min2:/home/sk#
So what you describe sounds perfectly fine assuming I understand what your described. The test page runs on the underlay network and by definition, the service you’re trying to secure using OpenZiti needs to be addressable. Openziti doesn’t secure the service from the underlay from the same host machine, that’s not possible. Any other devices trying to access that test service, those all need to be on the OpenZiti overlay in order to reach the test page.
Hope that helps
Thank you for your reply.
Just want to say it again, maybe I missed some information.
Windows PC can access the testpage.ziti and via IP.
Now my question is that if the web server is now secured and only windows pc (client installed) can access but how other users in the LAN (192.x.x.0/24) can access the web server via 192.x.x.1.
I mean others in LAN must not able to access it except the windows PC that has the client installed.
Web server should only be accessed by the client (windows PC) or if there’s other way around? This is my main concern.
Thank you so much
PS: Service output on Web Server (192.x.x.1)
systemctl status ziti-edge-tunnel.service
Aug 14 06:37:16 ub22-min2 ziti-edge-tunnel[14151]: (14151)[ 7113.565] ERROR ziti-edge-tunnel:ziti-edge-tunnel.c:1199 on_event() ztx[/opt/openziti/etc/identities/http-server.json] failed to connect to controller due to Ziti Controller is not available
Aug 14 06:37:18 ub22-min2 ziti-edge-tunnel[14151]: (14151)[ 7115.097] WARN ziti-sdk:connect.c:468 connect_get_net_session_cb() conn[0.0/Binding] failed to get 'Bind' session for service[testpage]: UNAUTHORIZED(The request could not be completed. The session is not authorized or the credentials are invalid)
Aug 14 06:37:18 ub22-min2 ziti-edge-tunnel[14151]: (14151)[ 7115.097] ERROR ziti-sdk:ziti_ctrl.c:252 ctrl_login_cb() ctrl[openziti] UNAUTHORIZED(The request could not be completed. The session is not authorized or the credentials are invalid)
Aug 14 06:37:18 ub22-min2 ziti-edge-tunnel[14151]: (14151)[ 7115.097] WARN ziti-sdk:ziti.c:1433 api_session_cb() ztx[0] failed to get api session from ctrl[https://openziti:8441] api_session_state[3] UNAUTHORIZED[-14] The request could not be completed. The session is not authorized or the credentials are invalid
Aug 14 06:37:18 ub22-min2 ziti-edge-tunnel[14151]: (14151)[ 7115.098] ERROR ziti-sdk:ziti_ctrl.c:252 ctrl_login_cb() ctrl[openziti] UNAUTHORIZED(The request could not be completed. The session is not authorized or the credentials are invalid)
Aug 14 06:37:18 ub22-min2 ziti-edge-tunnel[14151]: (14151)[ 7115.098] WARN ziti-sdk:ziti.c:1433 api_session_cb() ztx[0] failed to get api session from ctrl[https://openziti:8441] api_session_state[1] UNAUTHORIZED[-14] The request could not be completed. The session is not authorized or the credentials are invalid
Aug 14 06:37:18 ub22-min2 ziti-edge-tunnel[14151]: (14151)[ 7115.338] ERROR ziti-sdk:ziti.c:1370 ziti_set_api_session() ztx[0] local clock is 9904 seconds behind UTC (as reported by controller)
Aug 14 06:37:18 ub22-min2 ziti-edge-tunnel[14151]: (14151)[ 7115.770] ERROR ziti-sdk:ziti.c:1370 ziti_set_api_session() ztx[0] local clock is 9905 seconds behind UTC (as reported by controller)
Aug 14 09:53:49 ub22-min2 ziti-edge-tunnel[14151]: (14151)[ 9002.055] WARN ziti-sdk:conn_bridge.c:300 on_ziti_data() br[0.2] closing bridge due to error: -23(connection is closed)
Aug 14 10:05:31 ub22-min2 ziti-edge-tunnel[14151]: (14151)[ 9704.475] WARN ziti-sdk:conn_bridge.c:300 on_ziti_data() br[0.3] closing bridge due to error: -23(connection is closed)
@kashif I think I am understanding that your issue is, after setting up your network, your service is still reachable using both the IP and the service address through your ziti network.
Adding a service to the OpenZiti network isn't going to make your service unreachable by IP unless you block access.
One way of doing this is, say your web server is exposed on 123.45.67.89 port 12000. As long as the IP and port are exposed, it will be accessible by IP. However, if we then close port 12000 on the firewall, now the only way to access it is through the ziti network. Since port 12000 is closed, it's not accessible. But, if going through the OpenZiti network, it would be accessible.
If I understand your issue correctly, what I would do is change the port that the web server is exposed on to something more unique (i.e. not port 80/22/etc, pick something like 12000). Once your network is up and configured so you can reach your service, close port 12000 on your firewall (assuming it was open), but if you're working on a local network, local devices will still have access, so to block those you can open up the Windows firewall for the computer itself. Example steps below that I took from here
1. Go to Start -> Control Panel -> System and Security -> Windows Firewall.
2. Select ‘Advance Settings’ -> ‘Inbound Rules’ (to block an inbound port)’ OR ‘Outbound Rules’ (to block an outbound port).
3. Select ‘New Rule‘ choose ‘Port‘ from options and click Next.
4. Choose ‘TCP‘ or ‘UDP‘ and click on ‘Specific Local Ports‘.
5. Enter the Port Number and click ‘Next‘.
6. Click ‘Block the Connection‘ and then click ‘Next‘. Choose the network location (public, private, domain) on which the rule applies and click ‘Next‘.
7. Create a Rule name and add a description for it. Click on ‘finish‘ to block ports on a computer.
I think this is just coming down to how you're trying to run the ZAC. I assume you've followed the quickstart. That quickstart will bind ZAC to 0.0.0.0 which means it will be available to any client on the local network. If you instead want to make the ZAC only accessible from that computer it's running on, you'll have to restrict the firewall on the machine. Right now there's no way to make the ZAC bind to 127.0.0.1, it'll bind to all interfaces.
I have added an issue to the ziti-console project to track this request Allow binding to specified IP · Issue #160 · openziti/ziti-console · GitHub
Until then, the only way to prevent ZAC from being accessed by other machines is to use the windows firewall and deny access.
Hi,
Thank you for your reply.
I think I am understanding that your issue is, after setting up your network, your service is still reachable using both the IP and the service address through your ziti network.
Yes and for example say your web server is exposed on 123.45.67.89 port 12000 is accessible even without ziti network.
So the suggestion/advice is it to block port 12000 (on web server) so that no one can access it accept the ziticlient which goes through tunneler. Right!
Thank you so much.
Yes, that was one case.
Another was that I replied to @gberl002
I think I am understanding that your issue is, after setting up your network, your service is still reachable using both the IP and the service address through your ziti network.
Yes and for example say your web server is exposed on 123.45.67.89 port 12000 is accessible even without ziti network.
So the suggestion/advice is it to block port 12000 (on web server) so that no one can access it accept the ziticlient which goes through tunneler. Right!
Hi,
The thing I understood uptil now.
If the tunneler is installed in a web server (lets say “123.45.67.89 port 12000”) and if I don’t want anyone in the LAN or WAN to able to access the web server then I must block the port 12000 on web server itself? Correct? Or if there’s a policy in ZAC that I block 12000 without using firewall?
By this way the web server is only be accessed via tunneler (let say windows client). Is this right? Just need clarification.
@TheLumberjack @gberl002
Thank you very much
Yes that's correct. The other way to accomplish this is to have ZAC bind ONLY on the loopback (localhost/127.0.0.1) but that feature is not implemented yet, so you cannot do that at this time. That's why I filed the issue: Allow binding to specified IP · Issue #160 · openziti/ziti-console · GitHub Until that issue is done and fixed, you can only do this by disabling inbound access to the server using the windows firewall.
It seems that your current LAN is set to the "private" zone, which often allows other connections from people on the same subnet. You don't have to do that, but it seems to be how your machine is setup.
For example, at my home, I can RDP from another computer to this one because I allowed remote RDP connections. At some point, you must have (or windows defaulted to it?) allowed other machines on your local network to access services on that machine. For now, until that issue I linked is done, you must use the windows firewall to block access to ZAC, given your apparent current configuration.
With 2.8.7 of the ziti console you can now bind ONLY to 127.0.0.1.
After cloning the ziti-console, modify the file at ./assets/data/settings.json and update "bindIP": "" to be: "bindIP": "127.0.0.1"
Right now if you run sudo ss -lntp you’ll see the ports are listening on ALL interfaces * for both port 1408 and 8443.:
sudo ss -lntp | grep -E '1408|8443'
LISTEN 0 511 *:1408 *:* users:(("node",pid=178237,fd=18))
LISTEN 0 511 *:8443 *:* users:(("node",pid=178237,fd=19))
Edit the file, update the bindIP and restart ziti-console using: sudo systemctl ziti-console. Afterwards, you can see the port will be only available on 127.0.0.1:
sudo ss -lntp | grep -E '1408|8443'
LISTEN 0 511 127.0.0.1:1408 0.0.0.0:* users:(("node",pid=179120,fd=18))
LISTEN 0 511 127.0.0.1:8443 0.0.0.0:* users:(("node",pid=179120,fd=19))
Here’s a small gif showing it. Now you can have ZAC listen only on 127.0.0.1 if you wish:
Thank you so much for your help and guidance.
Is there any plan on how to restrict/block port for other servers when the tunneler with service is installed instead of blocking?
Thank you
I’m not quite sure what you’re asking. The feature we just implemented in ZAC to bind on select IP addresses is something any application that exposes a service on the network needs to implement. There’s no way for OpenZiti to influence those applications. Blocking them via OS firewall is the only way to accomplish it, assuming I understand what you’re asking.
Thank you
ZAC to bind to localhost was important. thank you so much.
Another question was
I asked that I have a local web server (not ZAC) that runs at 80. Which all users are accessing it in LAN network and I think via VPN clients.
I installed a tunneler in local web server and I want this server to be accessed via ziti network only. So the suggestion came to block the port 80 in local web server. This way no one can access local web server except the tunneler installed in client machines.
Thank you
Right. You have two basic options, block port 80 with firewall, or figure out if the application implements the same feature we just did with ZAC, which is to allow the app to bind only to the loopback interface.