• Deployment Basics
• Intranet Development
• Internet Deployment on your own Server
• Internet Deployment on a Hosted Server
• Installing NetTalk and IIS on the same machine. (Same port, different IP number.)
• General Notes on the Security of hosting a Web Server

One of the main benefits to using NetTalk as your platform of choice is that deployment is really really easy. There are no dependencies on IIS, Apache or any other web programs. Deploying a NetTalk program is exactly the same as deploying a normal Windows 32 bit exe.

Of course a proper Windows install, such as one made with SetupBuilder, is the first step for a professional install. Please take note of the files you need to distribute in your application folder (in the Distribution section of the main NetTalk document) if you are using TLS.

To deploy on your own server is no more difficult than installing any normal Windows program. Typically you will need:

1. The Exe, plus any support files (DLL's, TPS, INI's etc) in a folder and
2. The caroot.pem and DH2048.pem files, which are copied into your application folder as part of the compile process
3. The "Web" folder, and sub folders containing the images, scripts, and style files. These are automatically copied into your application folder when your program is compiled. The original files are in \Clarion\Accessory\LibSrc\Win\NetWeb .

Then either run the exe as a program, or if you have made it into a service (using SelfService) then run the exe with the /iss command line switch to install it as a service (and start it running.) For example:

web31.exe /iss

Port number considerations

Installing on your own server, but for access by users outside the LAN is fairly straightforward.

Firstly install the program as if for LAN users, as described above.

Then create a route, so that users from outside can access this port on this machine. This will mean going to the settings for your ADSL (or Cable, or Whatever) router/modem and explicitly open port 80 to the outside, so that users connecting to your modem (from the outside on port 80) get redirected to the internal machine. This process does vary from router to router, but is usually fairly intuitive.

Since your users will not want to type in an IP number to access your new site, you will need to create a DNS entry for your domain, pointing at the new server. For example, at CapeSoft, I created a DNS entry called www.capesoft.com which means that people can type https://www.capesoft.com in their browser to get to one of our servers.

If you have a dynamic IP address issued by your ISP then all is not lost. All you then do is make use of a Dynamic DNS service which will keep your DNS up to date, to attach the actual IP address of your router. There are numerous such services available, for example www.no-ip.com.

If you would like your web site, or web program, to be on the internet, but you are unable (or unwilling) to host it yourself then there are any number of internet ISP's that will host it for you. Because you will be running proprietary software (ie the Clarion EXE you are writing) what you need is a dedicated server, either Virtual or Physical.

A Virtual Private Server (VPS) Machine appears to you as a dedicated machine, but is actually sharing a CPU with another machine. However your machine, and the other Virtual Machines on the computer are completely isolated from each other. From your program's perspective it's as if you were running on a dedicated machine. Virtual Machines offer improved security over shared servers, because one VM can't access the hard disk of another VM and so on. Just remember to get a machine with resources suitable for your needs. For example, if you are going to run a SQL server on the machine then it will need plenty of RAM allocated to it.

We've made use of the following service providers with success;

RackSpace: Prices range from $60 per month upwards for a VPS with 1 Gig of Ram and 40 Gigs of disk space.

Oak Park Solutions: Host both physical machines and virtual machines. VM prices run from $40 per month.

In concept, if your machine has 2 (or more IP addresses) then you can limit IIS to listening on one IP address, and you can set your NetTalk program to listen on the other IP address.

To "Bind" your NetTalk program to a single IP address, use the setting on the Advanced tab on the WebServer procedure.

To limit IIS to a specific IP address is slightly more difficult, and is explained below. Thanks to Ian Hickton for supplying much of this information.

A good discussion of limiting IIS to a specific IP address can be found here
http://support.microsoft.com/kb/813368

Be aware that IIS binds itself to ALL available IP addresses (it uses socket pooling !). If you want to use port 80 for your NetTalk server then you will need to add another IP address to your NIC and then tell IIS to use its own IP address.

The way to tell IIS to use a specific IP address is this:-

Open a command prompt window. (Press Windows-R, then type CMD).

For IIS 5.0 and 5.5, type
CD \Inetpub\AdminScripts
CSCRIPT ADSUtil.vbs SET W3SVC/disablesocketpooling TRUE

Wait for the response <BOOLEAN> TRUE

For IIS 6, type
CD\
HTTPCFG SET IPListen -i XXX.XXX.XXX.XXX:80 
( Replace XXX's with your IP address)

Tip: If you can't find the HTTPCFG program then look on your Windows Server 2003 CD, in the Support\Tools directory, it's part of the Support.Cab.

For all versions of IIS, now stop and start the web services using the commands below;

Type
NET STOP iisadmin /y

Wait for responses

Type
NET Start W3SVC

It's important to understand the risks associated with hosting a web server. By understanding what is happening you are better able to manage the risks involved.

First let's cover exactly what you are doing when you install a web server. To see the web server from the outside world, you will need to open PORT on your ADSL router. (This is sometimes referred to as a Pinhole). In your ADSL router this Port is routed to a specific machine on your LAN. This means that outside computers, can request a connection to your server, on (and only on) that one port.

Now it's important to note that it's your NetTalk Web Server EXE that is listening for connections on that port. It's not Windows, or anything else, just your EXE.

The incoming connection can pass requests to your program. Usually these requests are either a GET or POST. Your program then responds to these requests.

Like any program, your NetTalk EXE can only respond to commands it understands. There's no magic by which your program can suddenly do extra stuff - like run DOS commands. Of course you can program it to do anything you like, but outside of what you program it can't do anything.

Of course it's not completely that simple. If a remote user can get the server to crash, then it's possible to get the server to run very specific code passed by the remote user. This is a very difficult thing to do, and requires a user of very high skills. Which is not to say that every hacker is highly skilled. But of course a solution figured out by one hacker can be passed on to many many more.

It's important to note that your NetTalk Web Server is no different. If a remote user can cause it to crash, and if they work really really hard, they might be able to get malicious code to run. However you have a couple of advantages on your side;

a) Your NetTalk Web server is unique. Thus a technique that makes someone else's web server GPF will probably not work on yours.

b) It's built using Clarion. By far the most likely way to get a web server to crash in the first place is to pass it a malformed packet, which causes a buffer overrun. But because of the way Clarion works, it is not susceptible to buffer overruns in the first place. While it's possible to create bad code (obviously) by default Clarion makes it very unlikely your program will suffer from a buffer overrun.

c) Your program is build on "uncommon" technology. Given all the work involved in creating a viable attack, it's more likely for hackers to attack generic, well known, servers. The effort involved is less (because IIS, for example, is the same program from one computer to the next.)

Buffer overflows are not the only way to attack a web server. Other common techniques include HTML Injection, JavaScript Hacking and others. All these techniques are handled automatically by the engine (by default) although you should take care if you allow external users to enter HTML directly (and then allow it to be displayed.)

Some attacks, such as denial of service, are not related to the web server program at all and cannot be prevented by the program. These can happen regardless of where the program is hosted.

Finally, remember, Backups are your friend. Data should be backed up regularly, and data backups should not overwrite earlier backups. A successful attack is always a possibility and no guarantee can be made that one won't happen. So backups are a crucial element in preventing long-term data loss.