Skip Navigation
Self-Hosted Main @selfhosted.forum
martijn79 @alien.top
BOT

Bypass Palo Alto company firewall

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?

​

​

12 comments

  • 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.

  • First red flag your company is a joke: you have a local admin account.

    Seriously, do not circumvent your corporate security. You have literally zero defense to these actions and can be terminated immediately. Not if, but when it happens, you will also likely be blamed for any issues which arise even if they are not directly your fault. If you did have permission somehow to do this, I am not sure why you are asking for help on how to do this. If your company does allow this, it's even more of a joke than allowing a local admin account and that raises other questions.

    I allow my folks to BYOD on a (mostly) unrestricted BYOD/Guest network. Nobody has local admin accounts for any devices on the corp side. People can bring their personal laptops in and browse whatever and use VPNs on this network if they choose. There are some obvious restrictions (nothing illegal, for example), but if folks want to VPN to their self hosted environments or play on tiktok with their stuff, it's better for liability, better for security/compliance, and most importantly .. It is completely isolated from any corporate stuff. There is no need for circumventing when better options are available, promoting best practices for all employees.

12 comments