this post was submitted on 19 Oct 2023
-1 points (33.3% liked)

Self-Hosted Main

515 readers
1 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

For Example

We welcome posts that include suggestions for good self-hosted alternatives to popular online services, how they are better, or how they give back control of your data. Also include hints and tips for less technical readers.

Useful Lists

founded 1 year ago
MODERATORS
communick@selfhosted.forum
-1
Bypass Palo Alto company firewall (alien.top)
submitted 1 year ago by martijn79@alien.top to c/main@selfhosted.forum
12 comments fedilink hide all child comments
 

Hello,

My company is using a palo alto firewall which replaces the SSL certificate for every HTTPS site by a company generated one. I used to bypass internet filtering by creating a SSH tunnel with Putty (I am local admin and can run Putty on my laptop) and run it on port 443. Then add a socks proxy in my browser setting and I was done. No more SSL filtering and I could access any website.

But now the firewall is blocking this as well. SSH to port 443 is not working anymore.

I tried this: https://hacktr.org/blog/2020/01/01/ssh-tunneling-over-https/ but it didn't work either.

I also tried this: https://mariobrandt.de/archives/technik/ssh-tunnel-bypassing-transparent-proxy-using-apache-170/

But no go as well.

This has to be possible some way, by proxying apache to SSH using a letsencrypt cert. I tried to add a LE cert but the problem is when apache proxies to SSH it changes to IP ad the firewall blocks that step.

Any idea how to solve this?

​

​

you are viewing a single comment's thread
view the rest of the comments
[–] scorp123_CH@alien.top 1 points 1 year ago

I've worked in a similar environment before ... Maybe my approach will work?

USE AT YOUR OWN RISK

But I used MacOS and Linux for this. Or more specifically: The OpenSSH clients and tools such as "nc" (BSD NetCat) these OS come with. The only way I ever managed to reproduce this on Windows 10 back then was via using CygWin ...

Also: you'd need an OpenSSH server (BSD, Linux, MacOS ... these days Windows 10/11 would probably work too) somewhere somehow outside your company network, e.g. at home. I always used my own little Linux server at home for this.

So what I write here is with OpenSSH and "nc" (BSD NetCat) in mind.

Let's also assume that I want to access a remotely running RDP-server in my LAN (could be Windows, could be Linux via "xrdp" ... e.g. because I don't want my browsing history on my local company web browser ...)

Thus:

ssh -p $REMOTESSHPORT -L 3389:192.168.1.39:3389 user@remote -o "ProxyCommand=nc -X connect -x proxy.hostname.net:$PROXYPORT %h %p"

=> the RDP server (port 3389/tcp) running on my LAN host "192.168.1.39" becomes available as "localhost:3389" on my end, thanks to this SSH connection. And it will remain available for as long as this connection stays open.

Filled with actual numbers and names this could look like this:

ssh -p 2243 -L 3389:192.168.1.39:3389 myuser@myhost.athome.ddns-domain.nu -o "ProxyCommand=nc -X connect -x clientproxy.corporation.net:8079 %h %p"

Why port "-p 2243" => my router at home is set to port-forward SSH from 2243 to 22; I don't use the standard port 22 on the outside because there are too many script-kiddies out there who otherwise keep hammering that port with login attempts... Not that I am worried (I do SSH-key based logins and not password-based logins ...) but I just find the flood of failed login attempts annoying. So I moved the SSH port to something above 1024.

How this works:

What happens here is that the "nc" tool will first pretend to be a standard SSL client (e.g. a web browser wishing to communicate via "https" ...) and connect to the corporate web proxy on the port the proxy expects ("8079/tcp" in my example) ... and then keep the connection open. And then the actual SSH connection goes through that tunnel and connects to my actual target host: my machine at home.

In case you don't have an OS with BSD's flavour of "nc" (BSD NetCat) but something that uses e.g. Red Hat's "socat" instead: The syntax changes.

ssh -p 2243 -L 3389:192.168.1.39:3389 myuser@myhost.athome.ddns-domain.nu -o "ProxyCommand=socat - PROXY:clientproxy.corporation.net:%h:%p,proxyport=8079"

... but it should work just the same. For as long as this SSH connection remains open the RDP-server running on the LAN host "192.168.1.39" becomes available as "localhost:3389" ... so you RDP into your LAN, you open your web browser at home, you can surf away as you want ... And your browsing history stays at home and unless you somehow activated some cloud-sync feature (... why oh why would you?) it should never ever end up on your work machine.

Feel free to expand the number of ports (e.g. 5901 for VNC in addition to 3389 for RDP?).

File-transfer protocols such as SFTP or "rsync" of course work too ... In case you downloaded something and need it transferred:

sftp -P2243 -o "ProxyCommand=nc -X connect -x clientproxy.corporation.net:8079 %h %p" myuser@myhost.athome.ddns-domain.nu

rsync -av --progress -e ssh -p 2243 -o "ProxyCommand=nc -X connect -x clientproxy.corporation.net:8079 %h %p" 2>/dev/null myuser@myhost.athome.ddns-domain.nu:/path/to/remote/source/fileorfolder /local/path/to/destination/folder

​

Disclaimer: USE AT YOUR OWN RISK.

In my experience in most places where they catch you doing this at work and without permission, they fire + sue you.

Again: USE AT YOUR OWN RISK.