HTTP Proxy with a twist?

Hi folks,

Consider the following set up:
[Windows PC] ---> [F/W tcp/22/80/443/3389] ---> [FreeBSD jump host inside DMZ] ---> [SLES web server]

The jumphost provides the gateway to the web server from our corporate network - desktop users utilise X11 forwarding to launch Firefox/Opera browser from their Windows PC.

However, we have a new requirement that requires the use of Internet Explorer to view certain pages on the SLES web server.  

Given FreeBSD won't run IE, what are my options?  

I'm considering an HTTP proxy but not quite sure how this could be used given that the SLES web server is not directly reachable from the Windows PC.


Who is Participating?
Dave HoweSoftware and Hardware EngineerCommented:
use port 22 (ssh), preferably with putty (but any ssh client will do)

in putty, set up a listener on port 8080 and create it as "dynamic" type
in ie, set up a proxy of type socks4a (do *not* put anything in the http, https or ftp boxes) on port 8080

now as long as that putty is logged into the freebsd server (as *anyone*, so set up an unprivileged account and redirect its shell to rsh or even passwd) the end user's IE can reach any ip address the freebsd server can.

alternatively, you can set up tcp tunnels (local 80 and 443 to <ip of sles webserver> 80 and 443) and, without configuring any proxy on ie, type "" to reach the sles server.

this is called ssh tunnelling, and is just a *bit* powerful :)
Jason WatkinsIT Project LeaderCommented:
I'd change to the SSH port to something other than the default.
Brian UtterbackPrinciple Software EngineerCommented:
>the end user's IE can reach any ip address the freebsd server can.

Which is probably exactly what you don't want, otherwise you would not have a firewall and ssh and what you
already have in place.

The best solution depends on what constraints you have. For instance, DaveHowe's solution would work just fine, but it opens up your entire internal network to all outside users. Is it really just a single host that the users need to access? If they wil lbe forced to use IE, will they want to continue using firefox for the other pages, or would it be
better to dismantle this set up and replace it entirely with a proxy set up so all access is via IE running on the
external host? Perhaps you should push back on the requirement to use IE? What makes it a necessity?
On-Demand: Securing Your Wi-Fi for Summer Travel

Traveling this summer?Check out our on-demand webinar to learn about the importance of Wi-Fi security and 3 easy measures you can start taking immediately to protect your private data while using public Wi-Fi. Follow us today to learn more!

Dave HoweSoftware and Hardware EngineerCommented:
  That can be handy, but to be honest I would worry more about the 3389 and 80/443 than ssh; I see a lot more automated attacks against those two ports than ssh.

  I agree.... but that's what they *already have*, just currently using a xforward rather than a proxy arrangement (xforward is, in fact, a ssh tunnel. it just isn't labelled as one :). They have a firefox or opera instance, on the freebsd server, and can go anywhere that is allowed to go.  Adding a putty tunnel isn't going to make it any less secure (and indeed more secure, given the account can be restricted to not being permitted to run serverside code, which they can currently do; see the ongoing discussion regarding using stack overflow in xwindows to gain root...)

  And I have frequently seen sites that only work with IE - mostly because they rely on activex controls or ie-specific workarounds, which is poor programming but *common* poor programming. (I also had a 370 emu which only worked in IE, but that was because it used the MS java engine to support the tab key; I guess that is near extinct now :)
Brian UtterbackPrinciple Software EngineerCommented:
It is not clear to me that what they currently have involves x-forwarding via ssh. The quesiton author can clarify, but
it looks to me like they run firefox on the freeBSD DMZ system and display the window back on the PC. No tunnels involved. But I may be wrong.
denstaAuthor Commented:
Thanks Dave

The first option looks good but I know our users won't go for it - I will, however, store that one in the bank for another time.

The ssh tunnelling option is intriguing and has always been something I have struggled with.  So I did some reading and using my setup (substitue win for mac), assume I want to connect to SLESweb on 80 across the BSD jumphost:
[Mac] ---> [F/W] ---> [BSD] ---> [SLESweb]

Can I use:
ssh -f -L 3000:SLESweb:80 me@BSD -N

And then in the browser, use the URL http://localhost:3000 ?

[Plan to test this first thing in the morning]
denstaAuthor Commented:
sorry folks, a few comments came through while i was researching @DaveHowe's solutions.

@blu - some of the pages on the web server don't work with anything other than IE unfortunately (intranet site in an org dominated by MS prods)

we are currently using X11 forwarding to launch firefox/opera on FreeBSD which works just fine for most pages on SLES web server, but a few are broken and require IE.
Dave HoweSoftware and Hardware EngineerCommented:
blu: that's how xwindow display forwarding works - the exe runs on the server, but the DISPLAY variable is set to point to a ssh reverse tunnel that forwards that data back to an xserver on the client. that means they need a full xwindows server (which is the client - xwindows terminology is strange) to render the display stream when they get it.  You can do that for free with cygwin, or there are commercial xwindows installations for windows. to check what your tunnel is configured to, you can echo $DISPLAY provided you aren't using -N :)

densta: that's correct, yes. assuming they have a ssh command line tool on the client machine (normally on windows you use putty :). the dynamic tunnel would be "ssh -f -D 8080 me@BSD -N"

Note the fairly useful tool "proxypal" here - - it lets you toggle the proxy settings on and off in IE without having to go into the settings page each time.  

As for end user acceptance, I know if I had a choice between:

a) having to have a local xserver to run a display forward back down a ssh tunnel, just so I can run a web browser or

b) being able to run a standalone tool that requires no installation and is free from, use my own local web browser, and just connect to localhost (either in -D proxy or straight tunnel -L mode)

I know which one I would choose. I would have suggested foxyproxy (which lets you set such things on a per-host basis) but that is obviously a firefox not ie tool :)

that said, I use vnc (tightvnc on the server, vncviewer.exe on the client) over ssh tunnels all the time; its like full fat xwindows, but with no client side installation at all, you can run everything off a floppy with a simple batch file :)
Dave HoweSoftware and Hardware EngineerCommented:
Oh, in case you are interested in vnc (which is after all, low impact and free :) take a look here:
Brian UtterbackPrinciple Software EngineerCommented:
My point is that with the proxy set up with putty as you described, anyone that can access port 8080 on the DMZ
system can then open up a connection to any host inside, while in the current set up, only those that can log into
the DMZ system can do so.

I found one thing confusing, and that is when you said " port 8080". If that limits access on the FreeBSD
system to those already logged into the freeBSD system, then how would the IE back at the PC access it?

You could forward from the PC via ssh tunneling to the port on the freeBSD system that is in turn forwarded to the internal host. Is that what you mean? I missed that since you describe setting up only a single host and that would require a setup on two hosts. Actually, more since it would be once on the DMZ host and then again on each client PC.

denstaAuthor Commented:

option a) is acceptable IMO and is common accross my org, but as you say, requires a local xserver like xming running on the user's desktop in addition to putty.

i (heart) option b) though.  SSH Tunnelling is a beautiful thing and requires the use of only one tool and a simple set of instructions.

you mentioned an option c) in VNC - i've used vnc in the past but was under the impression it connects you to the console of the remote server which means only one user at a time can access it.  do i have that right?
denstaAuthor Commented:
Testing SSH tunnelling to the SLES web server worked beautifully.

Thanks all for your input.
Dave HoweSoftware and Hardware EngineerCommented:
No, vnc on windows works that way.
vnc on *nix has two modes;

1) you can have it present a gui login per-user

2) you can start it per-user from the ssh console, when it will assign a unique port per-user which is a persistent session - you can connect to it mulitiple times, sequentially or in parallel, and connect read-only or with full mouse and keyboard support.

most linux distros come with (1) pre-installed by default, just needing the applicable xinit line uncommenting.  they also come with (2), and this is triggered by typing "vncserver" while logged in as a suitable user. this mode has its own password (set when typing vncserver for the first time, and/or by typing vncpasswd)
Dave HoweSoftware and Hardware EngineerCommented:
@blu: no, you misunderstand. port 8080 is open only on the *workstation* and there, only from (loopback only). socks4a proxy (dynamic mode) is a feature of most sshd varients (including openssh, which is native to bsd and ported to other systems) so requires no special software on the bsd server.

because 8080 is open only to loopback, it is not accessable from anywhere else, but is accessable by the ie on the workstation because for it, its own is perfectly reachable :)
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.