0

I'm running Lucee Server, a cold fusion server engine that in my case runs on Tomcat, on Apache.

I'm looking into hardening it in various ways, and I'm running into a question about the SSH tunneling approach described here: https://docs.lucee.org/guides/deploying-lucee-server-apps/lockdown-guide.html#restricted-access-plus-ssh-tunnelling

The thing is, I don't think the description of how to do this ssh tunneling is accurate or complete. I spent a bunch of time looking at SSH documentation and also some other Stack Exchange questions (https://superuser.com/q/588591/504387, https://superuser.com/q/237977/504387) but still can't get SSH tunneling working as described in that guide or any other way.

Current setup, I have lucee running on server.example.com listening on port 8888. Apache running on the same server is listening on port 443 and is configured to proxy all requests to 127.0.0.1 on port 8888 (i.e. forward them to lucee). But it's configured to deny requests to /lucee as described in the above documentation.

This means the Lucee admin console can only be accessed directly at port 8888, not via port 443. Firewall rules (iptables) are set to allow incoming traffic on port 8888 only from the company internal network, so that we can access the lucee console but the outside world cannot.

This may be fine, but I was trying to see if I could make the tunneling approach work as described. If tunneling could work, we could ditch the iptables allow rule and just block port 8888 completely (except on loopback), or just reconfigure lucee to ONLY bind to 127.0.0.1.

SSH is on a nonstandard port on server.example.com, let's pretend it's 3300.

What I want to do is run an SSH command on my laptop that will:

  1. Use my existing ssh configuration and key to connect me to server.example.com (where sshd is listening on port 3300),
  2. Bind to whatever port on localhost on my laptop, let's say 60001,
  3. FROM the remote end at server.example.com, connect in turn to 127.0.0.1:8888 so traffic can be passed to lucee.

The end result should be that I can access http://127.0.0.1:60001/lucee/admin/server.cfm on my laptop and it will be received by lucee running on server.example.com and listening to port 8888 bound to 127.0.0.1 on that server.

How can I do this?

Improve this question

1 Answer 1

Reset to default
2

You should bind the Lucee Server only to localhost as it does not provide TLS on the port 8888. Then you have two options for accessing the administrative paths securely.

SSH tunnel

From ssh(1):

-L [ bind_address:]port:host:hostport

Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side.

Filled with the parameters from your question:

ssh -L 60001:127.0.0.1:8888 [email protected] -p 3300

Apache proxy with proper access control

As the proxy on port 443 is encrypted with TLS, you don't necessarily need SSH proxying at all, but you could allow connections to the administrative paths from company networks in Apache's configuration.

The documentation is a bit outdated, as the example is using Apache 2.2 syntax:

<Location /lucee> Order Deny,Allow Deny from all Allow from 127.0.0.1 </Location>

But the documentation on Apache 2.4 access control tells:

The Allow, Deny, and Order directives, provided by mod_access_compat, are deprecated and will go away in a future version. You should avoid using them, and avoid outdated tutorials recommending their use.

Say you would like to limit access to /lucee allowing only LAN 192.168.22.0/24 and public IP 198.51.100.22:

<Location /lucee> <RequireAny> Require ip 192.168.22.0/24 Require ip 198.51.100.22 </RequireAny> </Location>
Improve this answer
3
  • Thank you! Ironically, I had tried the ssh -L ... command earlier but hadn't realized how it was supposed to look; when I got the remote shell I thought I had messed up and I didn't try loading 127.0.0.1:60001 in my browser with that shell open. Commented Sep 11, 2023 at 16:14
  • Small follow-up about the Apache config suggestion: the issue with that is how to see the admin console for a specific webserver, since website.example.com goes through a load balancer so we wouldn't know which machine we're looking at. We can currently access the servers through internalservername:8888, and we could access through internalservername:443 if we took your suggestion, but then the browser complains because the TLS cert is only issued for website.example.com. I'm curious if your suggestion is any different in light of that info? Commented Sep 11, 2023 at 16:19
  • That sounds dangerous as it means the unencrypted port 8888 is listening on every interface instead of just the local loopback. It also sounds like the servers are sharing the same certificate & private key. Commented Sep 16, 2023 at 6:20

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.