Solved

HTTP Proxy with a twist?

Posted on 2010-08-22
14
766 Views
Last Modified: 2013-12-04
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.

Regards
Dennis

0
Comment
Question by:densta
  • 6
  • 4
  • 3
  • +1
14 Comments
 
LVL 33

Accepted Solution

by:
Dave Howe earned 500 total points
ID: 33500252
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 127.0.0.1 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 "127.0.0.1" to reach the sles server.

this is called ssh tunnelling, and is just a *bit* powerful :)
0
 
LVL 27

Expert Comment

by:Jason Watkins
ID: 33500486
I'd change to the SSH port to something other than the default.
0
 
LVL 22

Expert Comment

by:blu
ID: 33500502
>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?
0
 
LVL 33

Expert Comment

by:Dave Howe
ID: 33500758
@Firebar:
  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.

@blu:
  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 :)
0
 
LVL 22

Expert Comment

by:blu
ID: 33500860
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.
0
 

Author Comment

by:densta
ID: 33500966
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]
0
 

Author Comment

by:densta
ID: 33501105
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.
0
Complete Microsoft Windows PC® & Mac Backup

Backup and recovery solutions to protect all your PCs & Mac– on-premises or in remote locations. Acronis backs up entire PC or Mac with patented reliable disk imaging technology and you will be able to restore workstations to a new, dissimilar hardware in minutes.

 
LVL 33

Expert Comment

by:Dave Howe
ID: 33501251
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 - http://www.bartdart.com/ - 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 http://www.chiark.greenend.org.uk/~sgtatham/putty, 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 :)
0
 
LVL 33

Expert Comment

by:Dave Howe
ID: 33501279
Oh, in case you are interested in vnc (which is after all, low impact and free :) take a look here:

http://www.violetlan.net/bsd/27/TightVNCserveronFreebsdoverssh
0
 
LVL 22

Expert Comment

by:blu
ID: 33501852
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 "127.0.0.1 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.



0
 

Author Comment

by:densta
ID: 33506464
@DaveHowe

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?
0
 

Author Comment

by:densta
ID: 33508758
Testing SSH tunnelling to the SLES web server worked beautifully.

Thanks all for your input.
0
 
LVL 33

Expert Comment

by:Dave Howe
ID: 33509695
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)
0
 
LVL 33

Expert Comment

by:Dave Howe
ID: 33509744
@blu: no, you misunderstand. port 8080 is open only on the *workstation* and there, only from 127.0.0.1 (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 127.0.0.1 is perfectly reachable :)
0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

A few customers have recently asked my thoughts on Password Managers.  As Security is a big part of our industry I was initially very hesitant and sceptical about giving a program all of my secret passwords.  But as I was getting asked about them mo…
SHARE your personal details only on a NEED to basis. Take CHARGE and SECURE your IDENTITY. How do I then PROTECT myself and stay in charge of my own Personal details (and) - MY own WAY...
Learn how to navigate the file tree with the shell. Use pwd to print the current working directory: Use ls to list a directory's contents: Use cd to change to a new directory: Use wildcards instead of typing out long directory names: Use ../ to move…
This video shows how to set up a shell script to accept a positional parameter when called, pass that to a SQL script, accept the output from the statement back and then manipulate it in the Shell.

708 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now