Question

  • Creator
    Topic
  • #2138618

    Options for opening up an internal webpage to the internet

    Locked

    by greavette ·

    Hello,

    We have as part of an application we’ve bought from a vendor a webpage that will allow clients to login from the Internet and download the reports we’ve created for them. Currently we send these reports via email. Ideally I would prefer we send an email to the clients to let them know the latest report is available from our webpage. Our one requirement is to keep our solution local and not serve up these reports to an outside our network vendor to allow access from our clients.

    The webpage our vendor-app has made available requires a login and password and it lives on our primary server with a SQL database.

    I don’t want to open this up to the World Wide Web so my thought is to protect our primary database by pushing data from our primary database to another server/database in our DMZ. I would allow access from our internal network to the server in the DMZ but not allow access from the DMZ to our internal network. But I’m wondering if this is good enough.

    I’ve been looking at further protecting our data by using a clientless vpn solution such as openvpn-als (Adito). I have Adito up and running and have created a web forward and it works, but not without problems. The agent that gets installed on the fly from Adito will only work on Windows and I need to install a cert for this agent since I receive a certificate error on the agent (I have a cert on my Adito server already). I also don’t like the idea of having a client login through Adito and then have to login again on our internal webpage. Sure it’s more secure with two logins, but I can see clients getting bugged by having to keep two passwords.

    I’ve heard of ssh via html. I’ve been googling a bit on this and I’m still trying to understand how this would work, or if it would work in my situation. Does a client need to install anything on their computer before they could connect through ssh-html? Or is this over-kill to even think of using this.

    Another option I’m thinking of is to use my own solution to transfer these reports to clients. If I were to host my own sftp server webpage where each client could login with their own session and view/download reports. Or is this again over-kill and I should just let https handle the retreival of reports from this local server in our DMZ.

    Okay…I realize I’m jumping all over the place here. Any direction/thoughts you think I should take would be welcomed.

    Thank you.

All Answers

  • Author
    Replies
    • #2887976

      Clarifications

      by greavette ·

      In reply to Options for opening up an internal webpage to the internet

      Clarifications

    • #2887949

      How many clients?

      by rob kuhn ·

      In reply to Options for opening up an internal webpage to the internet

      How many clients are we talking? I also assume they pay for this service? Going off your comment about hosting an sftp server made me think about perhaps setting up a Business account with Box.Net or some other similar content sharing service. You would still have to upload the reports yourself but it would notify your clients. Although you may be able to use their desktop sync utility to take care of that for you.

      I understand your concerns about opening up your network. Do you have control of your firewall? Or is that offsite?

      • #2887899

        Reponse To Answer

        by greavette ·

        In reply to How many clients?

        Initially we would open this up to 10 clients. In the end I could see up to 150 clients using this to download their results. Yes, they pay for the service we offer them.

        We do have control of our firewall. We use Untangle on our Security Router to protect our network. There is VPN capability using Untangle but I don’t want to use a solution that requires our clients to install anything.

        I’ve used groupware systems like eGroupware and I’ve noticed some of these groupwares have a file management system. I could place a groupware in our DMZ and use the file management system to allow clients to download their reports.

        Any other ideas?

      • #2887885

        Reponse To Answer

        by rob kuhn ·

        In reply to How many clients?

        BTW- I looked a bit more closely at Untangle and do you just have the software or do you also have their appliance? If just software then I would really suggest you look into an actual hardware firewall.

    • #2887876

      Couple of thoughts here

      by robo_dev ·

      In reply to Options for opening up an internal webpage to the internet

      First of all, your DMZ idea is 100% correct, that’s how you expose apps to the web.

      Untangle is a very good app, but as Rob Kuhn recommended, in terms maximum throughput with least security risk, I would bet on a Cisco ASA or even a Sonicwall box to define the DMZ and provide the SSL VPN, if that’s the direction you go in.

      Hardware firewalls beat software firewalls anytime in most cases (exception Vyatta on VMware), and doubly so for a VPN solution where a lot of packet processing is needed, so when you scale up over 20-30 users, you’re going to hit the wall with anything server-based, while a hardware-based (e.g. hardware router/vpn) is what you will need.

      While a SSL VPN like Adito is more secure than just a plain server, it is not going to do exactly the same thing…serve up web pages. Their web-forwards are not quite the same thing.

      Don’t forget, an Adito box in your DMZ is a web server, with a login screen, and a database, and it needs to have one or more ports open. I know Adito OpenVPN real well, been using it for many years. (I am not meaning to say bad things about it, but it’s just a web server with an OS, and it needs to be configured/protected/monitored just like any other web server).

      I might add that Cisco ASA VPN router has a cleaner and better SSL VPN design than Adito (Cisco WebVPN), and unless you’re hosting Adito on a really fast server, the Cisco is going to scale better, be more stable, and has lots more features (you get what you pay for).

      Plus if you want to be 100% secure, add two-factor authentication (e.g. RSA SecurID) and then you do not have to worry about users setting weak passwords.

      Note, by the way, that the Barracuda Networks SSL VPN appliance IS a fork of OpenVPN (with LOTS more features). So if you want ‘Adito on steroids’ with better security, more features, and support, you just buy the Barracuda product. (Barracuda simply took the open source code, improved it, and made it closed source in their appliance).

      Can you make a web server in your DMZ secure? That’s a big ‘it depends’.

      It’s tricky to convey all that’s needed here in 5000 words or less, but here goes:

      First of all, https with a real (paid) certificate is required. It only solves a small part of the problem. You need to make sure the front door (authentication screens and authentication processes) are locked down, the server is patched, hardened, monitored, and logged. (Web server security 101)

      If money were no object, and your objective is to grant access (but not really expose the web app) you would define your DMZ with a Cisco ASA box, then setup a VMware server in the DMZ and host your web server as a guest VM on VMware. The Cisco WebVPN could publish the web pages off the web server in a secure fashion (and handle the authentication and encrpytion). Similarly, you could use the ASA box to simply serve up files for the users from a simple file server in the DMZ.

      Not to digress, but there are TONS of advantages to making the server virtual, both from a security, supportability, and recoverability standpoint. (it’s very easy and secure to create the DMZ within the vSwitch config of the VMware server, and run a virtual firewall appliance, such as Vyatta or m0n0wall, but I digress).

      If you want even more security, issue certificates to your users or even more security, issue them SecurID tokens.

Viewing 2 reply threads