by John Jung and William Robert Stanek
Webmasters typically deal with HTML or scripting questions. They're also expected to maintain the integrity of the Web server itself. Traditionally, Web servers ran off UNIX machines, which made security a very important issue. Sometimes the Web
servers had to interface with proxies and talk through firewalls. In some cases, the Webmasters were in charge of the proxies and firewalls themselves.
The security issues that face a Webmaster running the Personal Web Server are much different. Along with the traditional security issues of talking with proxies and firewalls, there are new concerns. The focus in this chapter is primarily on security
as it relates to Web page creation. Although there are still some concerns about restricting access to the Web server, this process is not as technical as it once was. This chapter explains the security issues that relate to the use of the Personal Web
Server.
Web servers that are directly accessible through the Internet have mainly server access issues. That is, you have to be careful of people accessing the Web server whether they connect from the Internet or the corporate intranet. Webmasters also have to
keep a watchful eye on the activities of the Web server itself. They have to watch out for tasks that the Web server performs that might jeopardize its security.
For traditional Web servers that run off UNIX machines, remote users accessing the Web server is always a security issue. The Webmaster must make sure that user accounts on the Web server have secure passwords. He must also be sure that the latest
security patches for various UNIX functions have also been applied. UNIX Webmasters have to worry about people being able to hack into their servers.
For people running a Web server on a Windows 95 machine, however, these issues aren't as prevalent. This is because Windows 95 machines don't offer many of UNIX's features; in particular, Windows 95 doesn't offer the capability to remotely log into a
computer over the Internet. Consequently, running Web servers from Windows 95 machines is less of a security risk. Because there is no way into a Windows 95 computer, there are fewer risks of the system being hacked into.
For those who want to have some of the power of UNIX but the friendliness of Windows 95, Windows NT is a good option. Windows NT makes much better use of the system's resources and offers better system protection than Windows 95. However, it keeps many
of the aspects of UNIX that are missing from Windows 95. These aspects include true user and group permissions and better networking. Although running a Windows NT Web server might be more work than running a Windows 95 server, it's well worth the effort.
Being a Webmaster also means being in charge of the content of the entire site. For both large and small companies, this responsibility involves ensuring that whatever is publicly available follows company standards. For example, the Webmaster must
make sure that Web pages on an Internet Web server don't hold confidential information. Company Web pages also can't contain copyrighted images, such as those from comic strips, movies, or magazines. Finally, the Webmaster of a corporate Web page must
ensure that the content isn't offensive. Pictures of nude people, offensive language, and similar content must be removed.
Another aspect of content control is that not all pages are accessible to everyone. A large business has many different groups, and each group has a particular focus. A particular group might want to limit its Web page to certain people. This practice
is not uncommon in large service-oriented companies where groups focus on particular customers. Each group can have a private Web page that only certain, specially designated people can visit. This kind of page enables customers and their corresponding
group to be able to view private information.
Another security concern with Internet-accessible Web servers is CGI scripts because the Web server typically runs CGI scripts as itself. This means that whatever permissions the Web server has when it is running, the CGI scripts have as well. Because
most UNIX Web servers run as either root (the superuser) or a regular user with extra functions, the CGI scripts can have extraordinary permissions. Consequently, the Webmaster must ensure that all CGI scripts are not potentially malicious. A possible
approach to get around malicious CGI scripts is to not allow anyone to create them. This is an acceptable method for many small- and medium-sized companies.
An intranet Web server is one that is accessible from within a particular domain. For large companies, internal Web servers are intranet Web servers. Intranet Web servers allow large companies to distribute private company information easily. Because
the information is often sensitive, intranet Web servers aren't accessible to outsiders. Just because the Web server isn't available to the world at large doesn't mean that security can be relaxed, however.
For many companies, content control means that the Webmaster must keep track of who has access to what. For example, the Webmaster wouldn't want an author from one group modifying the Web page for another group. Typically, tracking access isn't a
problem with UNIX Web servers because UNIX has well-defined user control. If the author of a page didn't want anybody to change her home page, she set her permissions accordingly.
Unfortunately, Windows 95 doesn't have such controls. Although there are definite user accounts and different user configurations, little file control exists. Anybody can sit down on any Windows 95 machine and delete and modify any and all files. This
makes running a Web server for a large intranet site unworkable under Windows 95. The acceptable alternative comes in the form of Windows NT. It does have many of the user control security measures that Windows 95 lacks. Also, because it's built on top of
the Windows interface, you don't need to learn UNIX commands.
Intranet Web servers, like Internet ones, should also be careful of CGI scripts. It might seem a little weird to be afraid of co-workers, but that's what security is all about. If an employee created a potentially malicious CGI script, the script could
cause problems if he leaves the company. If he's laid off or fired, he could easily use his script's malevolent aspects and cripple the Web server. Although this action could simply result in some downtime for the intranet Web server, it could also have
more dire consequences.
FrontPage comes with a number of facilities to help you, the Webmaster, control access to webs. This control comes in the form of restricting who creates Web pages as well as who reads them. Although most of this control takes place in the FrontPage
Explorer, where permissions are set on a per-web basis, you also use the Internet Services Administrator to control access.
Access control is divided into several broad categories. The first category called administrator is used to create accounts that have unlimited access to a particular web or to your entire site. Administrators can create accounts for their web, modify
Web properties, and change Web permissions. The second category called author is used for anyone who can create Web pages but isn't permitted to create webs or perform other administrative duties. The third category called browse is used for anyone who is
permitted to browse controlled areas of the web. To set up accounts in these categories, you use the FrontPage Explorer.
With administrator accounts, FrontPage makes it very easy for the site's Webmaster to delegate authority. For particularly large sites, there's probably a lot of different groups looking to publish a lot of different information. Because it's
unrealistic for one Webmaster to watch over all the content, FrontPage allows for lower-level Webmasters so each group can set up its own Webmaster to watch over the content of its particular web. The main Webmaster still has complete jurisdiction over
everything.
All accounts can be based on usernames or computer IP addresses. When you create an account for a user, you must assign the user a unique password. Whenever users access a secure area of the site, they have to authenticate themselves. When you create
an account based on IP address, you restrict privileges based on the location of the computer in the internal or external network.
To better control remote administration and authoring, FrontPage adds an additional layer of security for remote user accounts. You use the Internet Services Administrator to enable authors and administrators to create or manipulate content on your Web
site. Complete details for working with the Internet Services Administrator are provided in Chapter 37, "Personal Web Server Administration."
NOTE
As you work with access permissions, keep in mind that you can only set access permissions for webs created using a server. This means that you cannot set access permissions for any webs you create on your local file system. Generally, webs you create on the local file system are only accessible from the local system.
Any accounts you create in the root web have privileges in all other webs unless you specify otherwise. The reason for this is that Web permissions are based on settings in the root web. Typically, you want someone who can author pages in the root web
to be able to author pages in any of the other webs. The same goes for administrators who control webs and users who can browse secure areas of your site.
When you create accounts in the root web, you are creating an account with global privileges, meaning that unless you specify otherwise, the account has identical permissions in all other webs. In an environment where security is a concern, you should
not create accounts in the root web unless you are absolutely sure you want to grant complete access to your entire Web site. Instead, assign unique permissions to each web you create using the Permissions dialog box shown in Figure 38.1.
Figure 38.1. Setting unique permissions for each Web is a sound security practice.
CAUTION
The difference between a Webmaster who has control over everything to one who has control only over a particular web is in where you create the account. If you create the administrator account in the root web, you in effect create a do-it-all Webmaster who has access to all webs unless you specify otherwise. If you create the administrator account in a web other than the root web, the Webmaster only has control over that particular web.
To set unique permissions, do the following:
NOTE
The Settings tab is only available when the current web is not the root web. Further, only when you enable unique permissions are you able to edit the contents of a web's Users and Computers tabs.
FrontPage also allows you to create secure webs. In a secure web, all users are required to authenticate themselves before they are granted access to the web. Before you can create a secure web, you must first follow the steps for assigning unique
permissions to the web. Next, select Permissions from the Tools menu to display the Permissions dialog box and then click the Users tab.
At the bottom of the Users tab are two radio buttons (see Figure 38.2). To create a secure web, select the radio button labeled Only Registered Users Have Browse Access. Afterward, click the Apply button. Now all users have to authenticate themselves
before they can access the web.
Figure 38.2. Creating a secure web.
NOTE
The password protection extends to the entire subweb, not an individual page. You can't password-protect just one page with FrontPage. If you want to password-protect an individual page, you should create a subweb for it. Then, you can password protect just that subweb.
You create user accounts with the Users tab of the Permissions dialog box. This dialog box shows an alphabetical list of all users who have access to the current web. To the right of each user's name is a list of his access privileges. The access
privileges match the three categories of access controls. Users who can only browse the web have Browse listed by their names. Users who can author pages have Author and Browse listed by their names. Users who can administer webs have Administer, Author,
and Browse listed by their names.
To add a new user, click the Add button. This opens the dialog box shown in Figure 38.3.
Figure 38.3. Creating user accounts.
In the Name field, enter a username for the account. Typical usernames combine the first letter of a user's first and middle name with her last name. If the user has a long last name, you only use a portion of her last name. In this way, all usernames
are a specific length, such as eight characters. To create an account for William Robert Stanek, you could use the username wrstanek.
In the Password field, assign the user a password. For security purposes, all passwords should be unique and at least eight characters in length. FrontPage passwords are case sensitive. You can combine uppercase and lowercase characters in your
passwords. For strict security, passwords should contain a mixture of alphanumeric and non-alphanumeric characters. After you enter the password, re-enter it in the Confirm Password field.
The final step in the account creation process is to set user privileges. Select the appropriate access privileges for the type of account you are creating.
After you create an account, you can change permissions at any time by selecting the account in the Users tab and then clicking the Edit button. The only way to change a user's password is to log in as that user and select Change Password from the
Tools menu in the FrontPage Explorer. Alternately, you can select the account, click the Remove button to erase the account, and then recreate the account.
Computer accounts are not used like user accounts. Instead of granting privileges, you are setting the maximum allowable privilege based on the location of the computer. Restricting access to your Web site based on the location of a computer makes your
Web site more secure. Using computer accounts, you can ensure that only users of the internal networkyour intranethave administrator and author permissions. You can further restrict administrator and author permissions to specific computers
within the network, thus strictly controlling who has the opportunity to manipulate the content of your Web site.
To create computer accounts, you use the Computers tab of the Permissions dialog box. As you can see from Figure 38.4, the Computers tab is almost identical to the Users tab. However, accounts are organized numerically by IP address instead of
alphabetically.
Figure 38.4. Checking computer accounts.
IP addresses are broken down into period-separated fields. The value of these fields can tell you a lot about the classification and structure of the computer to which it refers. Part of the address identifies the network to which the computer is
attached and part of the address identifies the host computers attached to the network. Any field of the IP address that has an asterisk in it is a wild card that allows any value to make a match for that field.
When you install FrontPage, a default computer account is set all fields as asterisks. This means that any computer can be used to access your Web site.
If you are at all concerned with security, your number one priority is to close off this gaping security problem. The first step is to grant the computer you are currently using full access rights to the Web server. Click the Add button. This opens the
dialog box shown in Figure 38.5. In the IP Mask field, enter the full IP address of your computer without using any asterisks. Because this account should have full privileges, select the radio button labeled Administer, Author, and Browse This Web. Close
the dialog box by clicking the OK button. Now click the Apply button in the Permissions dialog box.
Figure 38.5. Adding new computer accounts.
Afterward, you should create an account with administrator privileges for the local loopback, which is usually 127.0.0.1. This ensures access to the server when you are logged directly into the Web server console.
Next, you should grant the appropriate level of privileges for computers within your network. Enter the IP address information that identifies your network to a level you feel comfortable with. You can use asterisks for some fields. If your network is
192.2.8
with host computers on your network identified as
192.2.8.1 192.2.8.2 192.2.8.3 192.2.8.4 192.2.8.5 192.2.8.6 192.2.8.7 192.2.8.8 192.2.8.9
You could create a computer account using the value
192.2.8.*
If you have multiple subnets, you can either create individual computer accounts for each subnet as shown previously. You could also use another asterisk field. For example, if you have three subnets
192.2.7 192.2.8 192.2.9
You could create a computer account using the value
192.2.*.*
If you allow remote access from computers not connected to your internal network, you should create a separate computer account for each computer. This account should have a fully qualified IP address, meaning you use no asterisks.
The final step is to change the access privileges for the default computer account. If you permit access to users outside the internal network, edit this account and change the level of access to Browse this Web. If you do not permit access by outside
users, remove the default account.
After you create an account, you can change permissions at any time by selecting the account in the Computers tab and then clicking the Edit button. To erase an account, select it and then click the Remove button.
Using the Internet Services Administrator, you can create accounts for administrators and authors who will remotely access the server. As you learned in Chapter 37, "Personal Web Server Administration," only local administrators can create
accounts. Therefore, you must start the Internet Services Administrator on the local machine. In the home page for the administrator, click the link titled Local User Administration.
Local user administration is performed with individual and group user accounts. When you first access the Local User Administrator, you see the page shown in Figure 38.6. This is the Users tab. You use the Users tab to create accounts for individual
users and the Groups tab to create group accounts. Ideally, you will have both user and group accounts on your system.
Figure 38.6. User administration in the Internet Services Administrator.
To create a user account, click the New User button of the Users tab. As shown in Figure 38.7, you can enter a username and password for the new account. You can change the password at any time by performing the following:
Figure 38.7. Creating user accounts in the Internet Services Administrator.
Group accounts are great for categorizing users. The Groups tab is similar to the Users tab (see Figure 38.8) As stated in Chapter 37, "Personal Web Server Administration," you might want to create separate group accounts for Web
administrators, which saves a few steps during account creation.
Figure 38.8. Group administration in the Internet Services Administrator.
To create a group account, click the New Group button of the Groups tab. You can now enter a name for your group. You can change the group name at any time by performing the following steps:
The User/Group tab allows you to easily add and remove users from a group. As you see in Figure 38.9, this page has two main areas: a user list and a group list. You use the User List to select users to add or remove from a group and the Group List to
select the affected groups.
Figure 38.9. Manipulating group membership.
To select items in the list, click them. By holding down the Shift key, you can select multiple items. You can add to a list of selections by holding down the Ctrl key when you make selections. When you are ready to add or remove users from groups,
click the appropriate button.
Whenever someone attempts to access the Web as an author, administrator, or user, a process takes place. This process, known as the authentication process, is used for both Web modifications and Web viewing. This isn't to say that there is one process
for intranet accesses and another for Internet accesses. The processes are in place for certain procedures; they are not dependent on where the person accessing the Web is.
The internal authentication process begins when someone attempts to access the web in order to modify it. Whether this is a modification of the Web page itself or just of its permissions, the internal authentication process occurs. FrontPage controls
the internal authentication process. This process begins when someone attempts to access a Web with the FrontPage Explorer. The user sees a dialog box from his Web browser (see Figure 38.10), where he enters his name and password. When he enters the
correct information, he is given access to the web.
Figure 38.10. When you try to access a protected Web page, Netscape presents this dialog box.
The external authentication process occurs when someone attempts to access a web. This process occurs regardless of where the machine requesting the web is located, so both machines on the Internet and intranet are subject to this authentication
method. Typically, no authentication is needed on these webs because most Web pages you create are visible by everybody. However, if you password-protect a web, the user has to enter a valid username and password before she can access that web.
You just purchased a car. It's blue with four doors. Is an alarm enough to secure it? In case the car disappears, its color and the fact it has four doors don't make much difference. I'm sure you aren't so casual about it. You probably have insurance
for it and list its vehicle identification number, any accessories it has, plate numbers, and so on. Believe it or not, many companies treat the security of their network assetsespecially data communication and internetworking assetsvery
lightly. Often, there are no security policies or any sort of record keeping; the security of their systems depends on less information than what you have about your car.
That's where firewalls come in, but a firewall alone does not secure your network. It is only part of a broader area of Web site and networking security in general. The complexities of firewalls, their components, and how to create them are far beyond
the scope of this book. However, this section covers some fairly general ground and discusses how FrontPage works with firewalls.
A firewall separates an internal network from the Internet. It screens and filters all connections coming from the Internet to the internal network, and vice versa, through a single, concentrated security checkpoint. You cannot reach the Internet from
the internal network, nor vice versa, unless you pass through this checkpoint. Some systems even require you to log onto the firewall. A firewall protects you against the electronic version of vandalism and helps you manage a variety of aspects of your
gate to the Web by keeping the jerks out and enabling you to concentrate on your job.
TIP
Using FTP, you can get information on firewalls from mailing-list archives at the following URL: ftp://ftp.greatcircle.com/pub/firewalls
A firewall toolkit and papers are available at the following URL:
A firewall greatly improves network security and reduces risks to servers on your network by filtering inherently insecure services. As a result, your network environment is exposed to fewer risks because only selected protocols are able to pass
through the firewall.
For example, a firewall could prohibit certain vulnerable services such as Network File Service (NFS) and Network Information Service (NIS) from entering or leaving a protected network. This prohibition provides the benefit of preventing the services
from being exploited by outside attackers while permitting people to use these services with a greatly reduced risk of exploitation. You can use services such as NIS or NFS, which are particularly useful on a local area network, to reduce the server
management burden without exposing the network to outside threats.
The problem with firewalls, however, is that they limit access to and from the Internet. In some configurations, you might decide to use a proxy server (which the "Proxy Service" section of this chapter explores in more detail) to filter the
inbound and outbound access your policy has determined to be safe. Although not necessary, proxies can be very useful.
A firewall can provide access control to site systems. For instance, some servers can be reachable from outside networks, whereas others can be effectively sealed off from unwanted access. Depending on the level of risk you are willing to take in your
Web site, you should watch out for outside access to the internal network servers, except for special cases such as mail servers. When setting up access control systems, keep the following rule in mind: Never provide access to servers or services unless it
is required. A good rule of thumb in access control is to keep the available servers and services to a minimum. This limits the number of possible break-in points on your system.
A firewall can be less expensive for an organization than security measures on individual machines in that all (or most) modified software and additional security software can be located on the firewall system instead of distributed on each server or
machine. In particular, one-time password systems and other add-on authentication software can be located at the firewall rather than on each system that needs to be accessed from the Internet.
Other solutions to your Web site security could involve modifications at each server system. Although many techniques are worthy of consideration for their advantages and are probably more appropriate than firewalls in certain situations, firewalls
tend to be simpler to implement because only the firewall needs to run specialized software. However, if you have a package-filtering firewall or require your users to log onto the firewall, you need either a router that filters the packages or a dedicated
machine.
CAUTION
Don't neglect internal security just because you have a firewall. If a hacker cracks in, your network is exposed unless you have some internal security policies in place.
Privacy should be of great concern for every Web site because what is usually considered innocuous information might contain clues that are useful to a hacker. By using a firewall, Web sites can block access from services such as Finger and Domain Name
Service (DNS). Finger displays information about users such as their last login time, whether they've read mail, and other items. Finger can also reveal information to hackers about how often a system is used, whether the system has active users connected,
and whether the system could be attacked without attracting the attention of administrators and other monitoring systems.
Some sites have independent internal and external DNS setups. The internal DNS setups have everythingall the names and IP addresses of your Web site. The external setup, which is the one accessible from the Internet, does not have all the names
and IP addresses available, only those important to other Internet servers. Some Web administrators feel that by blocking this information, they are hiding material that otherwise is useful to hackers.
By making all access to and from the Internet pass through a firewall, you can log accesses and provide valuable statistics about network usage.
TIP
A firewall with appropriate alarms that sound when suspicious activity occurs can also provide details on whether the firewall and network are being probed or attacked.
You should have a log of your Web site usage statistics and evidence of probing for a number of reasons. The first reason is to know whether the firewall is withstanding probes and attacks so you can determine whether the controls on the firewall are
adequate. Another reason is to track your Web server usage statistics as input for network requirements studies and risk-analysis activities.
Proxies are another form of security for networks. They are often applications running on a particular machine that control access. Proxies are often used to send data from inside the firewall to the Internet at large. You can think of a proxy as a
second line of defense for your network security.
Proxy services allow only those services for which there is a proxy. If an application gateway only contains proxies for FTP and Telnet, only FTP and Telnet are allowed into the protected subnet. All other services are completely blocked. This degree
of security is important. A proxy makes sure that only trustworthy services are allowed through the firewall and prevents untrustworthy services from being implemented on the firewall without your knowledge.
NOTE
If you have used TIA (The Internet Adapter), slirp, or TERM, you probably are familiar with the concept of redirecting a connection. Using these programs, you can redirect a port. Proxy servers work in a similar way by opening a socket on the server and allowing the connection to pass through.
A proxy is a special HTTP server that is typically run on a firewall. A proxy basically does the following:
Usually, all the clients in a subnet use the same proxy. This enables the proxy to efficiently cache documents that are requested by several clients.
NOTE
The fact that a proxy service is not transparent to the user means that either the user or the client must be "proxified." Either the user is instructed on how to manage the client in order to access certain services (such as Telnet and FTP), or the client, such as Web clients, should be proxy-aware.
Proxying permits high-level logging of client transactions, which includes the client IP address, date and time, URL, byte count, and success code. Another characteristic of proxying is its capability to filter client transactions at the application
protocol level. It can control access to services for individual methods, servers, domains, and so on.
Technically speaking, when a client requests a normal HTTP document, the HTTP server gets only the path and key word portion of the requested URL. It knows its host name and that its protocol specifier is http:. When a
proxy server receives a request from a client, HTTP is always used for transactions with the proxy server, even when accessing a resource served by a remote server using another protocol, such as Gopher or FTP.
A proxy server always has the information necessary to make a request to remote hosts specified in the request URL. Instead of specifying only the path name and possibly search key words to the proxy server, the full URL is specified. In this way, a
proxy server behaves like a client to retrieve a document by calling the same protocol that the client calls to perform the retrieval. However, the proxy creates an HTTP document containing the requested resource to return to the client. A Gopher or FTP
directory listing, for example, is returned to the client as an HTML document.
Therefore, a proxy server has a hybrid function. It must act as both client and servera server when accepting HTTP requests from clients connecting to it and a client (to the remote server) when retrieving the documents for its own client.
NOTE
A complete proxy server must speak all the Web protocols, especially HTTP, FTP, Gopher, WAIS, and NNTP.
With all the complexities involved in a firewall and proxy server, talking to one might be complicated. It's not. All you really need is to set up a proxy server somewhere on your network. That job is left up to the Webmaster who's also the network
administrator. There are entirely too many aspects of proxy servers and firewalls for FrontPage to cover. The only aspect that FrontPage lets you do is define an HTTP proxy.
To define an HTTP proxy with FrontPage, a Webmaster must load in a particular web. Presuming that he is an authorized Webmaster for that web, he can choose Options from the Tools menu and then select the Proxies tab. You can define an HTTP proxy server
by typing in the host name in the HTTP Proxy field (see Figure 38.11). In addition to the host name, you should specify a colon (:) followed by the port number that the proxy is using. FrontPage automatically takes care of the
communication between it and the proxy server.
Figure 38.11. All you have to do to use a proxy server is define its host name and port number.
You can also define other hosts on the same network that are inside the firewall. Simply enter the host names, and optional port numbers, of the servers in the List of Hosts Without Proxy field. These hosts are then able to use FrontPage as a pseudo
proxy. These hosts can talk to the FrontPage host, which in turn talks to the proxy server itself. Use a comma to separate multiple entries in the list.
After you've defined a proxy server, that server name is only used when you try to access the Internet. For example, when you try to use the Open Location command to point to a Web page outside the firewall, the proxy server is used. Similarly, when
you try to open a link to an external Web page with the Editor, the proxy server is used. Finally, FrontPage accesses the proxy server if you use the Follow Link command in the Editor to follow an external Web page.
Some people need to send secure data with a Web server. To secure data, the Web server can encrypt the data to be sent. This form of data protection is typically used when you want to conduct transactions across the Net. Most methods of data encryption
for Internet transmission are fairly secure. This feature is often the domain of advanced Web servers, so it is not available with all Web servers. Such is the case with the FrontPage Personal Web Server, which has no provision for data encryption.
If FrontPage accesses an encryption-capable Web server, the encrypted data merely passes through FrontPage, without ever looking at it. What this means is that you can safely send encrypted data through the Personal Web Server. You can't send
encrypted data with the Personal Web Server.
After all the Web pages are created for your web, you'll want to be able to access it. You can access the Web server from both inside and outside the firewall, and each kind of access raises different issues to consider. Fortunately, with proxy servers
in place, accessing your Web server is not a problem.
If you're sitting behind a firewall, accessing an external Web server isn't a problem. Follow these steps:
Figure 38.12. You can access an external Web server from behind a firewall without a problem.
Depending on the type of firewall you're sitting behind, you might run into some problems. These problems all point back to your firewall blocking the data being sent through the firewall. It's not necessarily blocking your data going out but rather
data going in. The best way around this situation is to use an HTTP proxy server that'll allow both sides of a firewall to talk to each other. Without the proxy server, and depending on your firewall, you might not be able to access an external Web server.
Suppose you're trying to access a Web server from outside a firewall. If the Web server you're trying to access is Internet-accessible, you will have no problems. You can access the internal Web server from outside the organization's domain. However,
if the internal Web server you're trying to access is behind a firewall, you'll have a problem. The only way to access an internal Web server from outside the firewall is with a proxy server. If your organization doesn't have a proxy server in place, you
won't be able to work on the internal server at all.
Web server security is a very important part of being a Webmaster. It includes security for the Web server itself as well as its content. For maintaining content security, FrontPage gives you a good set of tools. These tools take the form of defining
accounts for other Web administrators and Web authors. In keeping with the theme of maintaining content security, you can restrict access to certain webs by defining user accounts for end users for each web. User accounts enable you to have part of your
Web site be public while another part is private.
Another aspect of Web server security is to prevent unauthorized people from accessing your system. Two methods of doing this include using firewalls and proxy servers. FrontPage gives you a very basic mechanism for communicating with them. Actually
setting up firewalls and proxy servers are matters best left to the organization's network administrator. The complex issues involved in firewalls and proxy servers are beyond the scope of FrontPage.