Skip to main content
replaced http://stackoverflow.com/ with https://stackoverflow.com/
Source Link

You should prevent the user from storing their passwordsprevent the user from storing their passwords on their devices. (This can be bypassed with plugins in browsers like Firefox.)

You should prevent the user from storing their passwords on their devices. (This can be bypassed with plugins in browsers like Firefox.)

You should prevent the user from storing their passwords on their devices. (This can be bypassed with plugins in browsers like Firefox.)

Source Link
AbsoluteƵERØ
  • 3.1k
  • 19
  • 20

How secure do you need to go?

This is probably as "secure" as you can make it. It's not technically safe. As Rook said, there are still things here than can be exploited. These are a few steps you can take to try and harden the system:

  1. Setup the web server on a physical server on the office LAN. Do NOT use NAT to connect any outside traffic to the webserver. If the server is used for other sites they should be on a different server or VM.

  2. Setup an SSL VPN firewall (Cisco comes to mind). Cisco has apps for iPads that can be used to setup a "secure" tunnel with the router.

  3. Once you've authenticated via VPN (remotely) you would assign a local IP address within a certain specified range (this depends on the number of clients connecting to the server). Depending on the router you can assign rules. Because you can't control the network on the other end of the VPN (let's say the user's home network) then this is a potential attack vector.

  4. Local traffic and VPN traffic would need to have different IP ranges for tracking. Local traffic should have static IP addresses assigned by MAC address (spoofable) by the DHCP server which are all logged. This will help you check for collisions and spoofed IP addresses and MAC addresses.

  5. On the firewall on the webserver you would setup a subnet of addresses that can connect to the web server. This would include the VPN range assigned in the router for the users and the whitelisted internal static IP addresses.

  6. Then on the web server itself you can restrict access to the website via the whitelisted ip addresses (IIS 7 and Apache) you've setup in the DHCP server and in the local firewall (this is redundant in the event someone finds an exploit for altering iptables in a *Nix box).

If you use a corporate after market software firewall like Kaspersky (on a Windows or Linux box) you can block traffic that way too.

To make changes to this system:

  1. the ip address lists would need to be updated on the internal DHCP server
  2. in the webserver's firewall
  3. and in the webserver config

So that "locks down" the access to the actual web server...

Next you'll need to run SSL on the webserver and require a specific username and password for the user. The password should be at least 16 characters.

Once the user authenticates on the webserver, then you would send them a message, either via SMS or e-mail that contains a single-use or one-time password that allows the user to be whitelisted for some set amount of time on the server. (If anyone has access to the user's cell phone this might be compromised). If the user closes the browser window they have to be reauthenticated (and this should terminate the session). You can set a keep-alive script that runs in a language like Javascript that expects a transmission from the client within a certain range of time. If the client doesn't answer, then kill the session. (This prevents disabling javascript for access. Also it helps with people closing their browsers and trying to open new sessions before their old session has expired.) They should only be able to login from one location at a time.

You should prevent the user from storing their passwords on their devices. (This can be bypassed with plugins in browsers like Firefox.)

To make things more strict you could even go as far as requiring the tablets to login to a virtual terminal via something like VNC or RDP (Not ideal on a phone). Then they would have to use the web client on the virtual machine. This VM would be restored to clean on the next run or connection.

Anyone who knows the system can exploit it. Anyone outside the system would have to spend a lot of time trying to get in and they would need to know the system existed.

All aspects would need to be documented. If someone had the documentation they could try to find a weakness in the system.

Again this comes down to people. Anyone with access to the information over time could store copies of all of the information (screenshots with a cell phone, texted PDFs of office documents, etc.) SSL is also crackable, so even encrypted "secure" connections can be read by the right people.