Accessing CIFS Shares via Luminate Secure Access Cloud
CIFS protocol (a part of SMB protocol) is delivered over standard TCP ports - 445 and 139 (it can also use UDP ports 137 and 138). If it is absolutely necessary to access native CIFS shares via Luminate Secure Access Cloud (TM), it can be done via SSH Tunnel to a destination port 445 of the eventual File Share server. The architecture is described in the below diagram:
To obtain access, for each File Shares server, the following operations need to be performed on each accessing client/workstation:
Below steps explain how to perform the above on Mac OS X and on Windows Workstation. Please notice, that the procedure for Windows Workstation is extremely complex, and, while it can be automated with attached scripts, it is not recommended for use. Access via SFTP client is much more stable and has better performance.
Step I - Bring up an additional Localhost Interface
Unlike in other Operating Systems, Mac OS X assigns, by default, only the 127.0.0.1 IP address to the loopback interface. In order to add another IP address, the following command needs to be run:
|sudo ifconfig lo0 alias 127.0.1.1|
Where 127.0.1.1 is the IP address that will be used in the following steps to create a tunnel to a CIFS server.
Step II - Configure an SSH Tunnel
In this step we need to create a tunnel to the destination server's TCP port 445. Please refer to this article for details on TCP Port Tunneling via SSH.
|sudo ssh user@firstname.lastname@example.org -L 127.0.1.1:445:Destination-IP:445|
With the following parameters:
Please note, that, as we are forwarding a privileged port (445), the command needs to be executed with sudo.
Step III - Connect a built-in CIFS Client on Mac OS X to the File Server
Launch a Finder Application, then in the menu pick "Go" --> "Connect to Server":
Type the IP address of the loopback interface we used in the previous step to create a tunnel and specify a share path (in this example, "Share1").
The Finder window with the share content will open:
In order to perform the same operations on a Windows Workstation, unfortunately, the process is more complicated. The complication is due to the fact, that, unlike in Mac OS X, on Windows Workstation (or Server) a local lanman service serves as a CIFS Server and listens to TCP port 445 on all interfaces.
Below steps are describing the process required to circumvent this problem. They are based on a process described at: https://www.nikhef.nl/~janjust/CifsOverSSH/Win10Loopback.html
Step I - Install a dedicated loopback interface Network Adapter
hdwwiz.exeThe Hardware Wizard will come up:
Step II - Configure the Network Adapter
Network adapter that was just added must be configured either manually or via a script.
These are the manual configuration steps:
Now that your newly installed loopback adapter is up and running we must configure it properly:
Alternatively to performing the above configuration steps, following PowerShell snippet can be used:
# Get the latest create kmloop adapter and rename it
# Update interface metric to 9999
# Define additional IP Addresses
The script defines two additional IP addresses - 10.255.255.10, 10.255.255.11 and also renames the adapter for a more convenient management.
Step III - Tweak the lanman service for a later start and define port-proxy for creating a tunnel
In order to be able to perform SSH Tunnel for port 445 on the IP Addresses defined above we need to delay the start of the lanman service and have the port-proxy service start listening to this port first. If we don't do this, despite the fact that we have disabled "Client for Microsoft Networks" on our new adapter. lanman will still try to listen to these IP addresses.
This configuration is done via the following PowerShell snippet:
# Delay the start of lanman, use "demand" instead of "delayed-auto" if this operation is denied
sc.exe config lanmanserver start= delayed-auto
Please note that the proxy should be added for each IP address that will serve as a connection to a File Shares server. Also, please note that the IP address is used twice in the command.
Step IV - Reboot and, optionally, validate that the system is ready
After performing the above configuration commands, the system can be rebooted. After the reboot, following commands can be executed to verify that the configuration operates correctly:
Step V - Create the tunnel and connect to the shares
Any SSH Client capable of creating an SSH Tunnel can be used (including, but not limited to Putty, MobaXterm, SecureCRT and more). In the below example, we will use Win32-OpenSSH command line ssh client (calling it from a PowerShell):
Start-Process -Windowstyle Minimized -FilePath "C:\OpenSSH-Win64\ssh" -ArgumentList "-L 10.255.255.1:44445:10.0.4.17:445 -i C:\Path\To\Cert\luminate_ssh_key.pem -l username@bastionname bastionname.tenant.luminatesec.com"
Step VI - Access the shares
Accessing the shares can be done "natively" via Windows Explorer. Just navigate to \\IP-Address\Share_Name, where IP-Address is one of the IP Addresses defined above, and Share_Name is one of the shares. Navigating just to \\IP-Address to see all the exposed shares is also possible.
PowerShell snippets implementing the above steps (requiring adjustment/modification to paths and IP addresses) can be found attached to this article.
Accessing CIFS (SMB) Shares over the internet is not recommended. This protocol is optimized for Local Area Networks. The below guidelines are not recommended (and will not be supported) for production-grade massive usage. Instead, the recommendation is to use SFTP and SCP access to File Shares.
Subscribing will provide email updates when this Article is updated. Login is required to Subscribe
Thanks for your feedback. Let us know if you have additional comments below. (requires login)
This will clear the history and restart the chat.