Overview

This topic discusses how your FotoWeb can be implemented in your network and the effect this has on security.

Implications of securing a web server

Running a web server on the Internet requires knowledge about many security issues. FotoWeb has been designed to fit into the Windows security model. The concepts for managing security in FotoWeb should therefore already be known by those familiar with Windows security.

FotoWeb uses the Process Account configured in the Operations Center to run the system. The account password is stored in encrypted form in the FotoWeb configuration files. If you change the account passwords in Windows, you must always remember to update the password in the Operations Center, and in IIS if your FotoWeb is hosted on that web server. If you try to start FotoWeb with the wrong password, the account may be locked out by Windows, and FotoWeb will not work correctly until you enter the correct password and unlock the account using the user administration tools in Windows.

Placing your server directly on the Internet

Placing your server directly on the Internet is an affordable solution. It ensures that a firewall completely protects your internal LAN. It is also an optimal solution for performance, as users have direct access to the FotoWeb server.

With this topology, it is difficult, or even impossible, to secure the operating system from hacker attacks, and it is not recommended unless performance or budget is a key issue.
 

Protecting your internal LAN behind a firewall

Another affordable option is to place the FotoWeb server on your internal LAN, which is protected by a firewall or a packet filtering router. The firewall must be configured to allow HTTP traffic to pass through to the FotoWeb server.

In addition to providing basic protection for your server behind a firewall, this setup allows your internal users to work directly with the archive using the Fotostation or FotoWeb clients. It is easy to manage your servers, and your internal users have optimal performance when accessing the archives.

However, if a hacker compromises your web server, your entire network will be vulnerable to attack.
 

Placing FotoWeb in a DMZ

More advanced firewalls can be configured with one or more ‘Demilitarized Zones’. A DMZ is a separate network where you can place servers that are accessible from the Internet. In this configuration, internal users can work with the archive using Fotostation at full speed and with functionality. The firewall needs to be configured so that the FotoWeb server can access the share containing the documents on the Index Manager server and to communicate with the Index Manager server over IP (port 7000 by default). FotoWeb accesses the document folders using standard Windows shares (using the NETBIOS protocol).

This solution is not optimal from a performance standpoint. FotoWeb needs to access all the files through the firewall, which can significantly affect performance. A hacker may also be able to exploit this tunnel in the firewall to attack the internal LAN after compromising the web server.
 

Placing all servers in the DMZ

Using a firewall with DMZ capability, you can place both the Index Manager and FotoWeb servers in the DMZ. The firewall allows traffic to the DMZ, but not to the internal LAN. Even if a user can compromise your web server, it is still impossible to attack the internal LAN.

This solution affects the performance of internal users. If they are using Fotostation to manage the archive, all access must pass through the firewall, which is slower than when the server is on the same network. However, the security gained by this solution may justify the performance degradation.
 

Using mirrored systems

If you have a large production workflow on your servers, it may not be a good option to access the document archive through the firewall as in the previous example. In this case, you may benefit from running duplicate servers. One set of servers is accessible from the internet, while another set is private to your internal LAN. This introduces complexity in duplicating data between the systems, but ensures maximum performance and security. However, it introduces the costs of licensing the software for more servers.

If you have a production workflow in your internal system and only provide a subset of the documents in the external archive (for example, the production results), this solution is ideal.

A one-way mirror is also quite easy to implement. However, if changes are made in both systems, this solution may present challenges that are either very difficult or impossible to implement.