RDUonline -- Policies and Security

We'd like to apologize in advance for the following legal necessities. No one disdains the need for a policy statement more than us, but to avoid any misunderstandings, here goes:

Site restrictions.

Sites promoting or offering pornographic images are not hosted on our servers, sorry. Sites promoting multilevel marketing, gambling, and pirated software known as warez are also not permitted. We respect your right to host the materials you choose, and reserve the right to exercise editorial control on these issues. Besides, our lawyers are much happier with this, and they can beat up other lawyers easily.

IP addresses.

IP addresses can be supplied upon request and with appropriate reason, provided they are used in a fashion compliant with RFC2050 and other registry guidelines. For more information about the guidelines which govern the 'net, BCPs, STDs, RFCs (Requests for Comment) and such, visit one of the many on-line libraries here.

Terms of Use:

SPAM generation or attempts to bulk email unsolicited materials is an unacceptable use of POP/SMTP services provided to your account. Doing so can affect users beyond your own account, and will not be permitted from these servers. The account owner responsible for all account behavior, whether or not that individual originated the behavior. Accounts which participate in SPAMMING will relinquish rights to POP/SMTP accounts and/or be libel for administrative fees not to exceed $1500.00 for rectifying costs incurred including hourly time logged by RDUonline staff. Any and all files related to those POP/SMTP accounts will be purged from the system. Additional actions will be taken as necessary, up to and including the cancellation of all accounts related to the account owner without refund. (This is one of the only things we are serious about.)

The account will not be used for any illegal activities. Use of your site will comply with all laws and regulations of the Federal Code of the United States of America and the laws of the State of North Carolina. (This is another of the few things we are serious about.)

Do not use copyright material on your site without the consent of the copyright owner. (That is illegal.) Respect trademark legalities, too.

Do not release your login identification or password to anyone outside of your web developer. This includes but is not restricted to your FTP log in, secure realm login, eCommerce access login, email login or any other secure feature. Breach of any security by a third party to any component of your site(s) by ID/password entry is completely in your hands. We will not, under any circumstance, ever have need to request your password for any reason. Ever. If you feel your security has been compromised, it is your responsibility to contact us or your account representative immediately to have your security information re-assigned. No party except an individual previously-designated by the owner of an account may request security information or the alteration of security information. Did we mention never release this stuff? O.K., then.

Do not help people break into sites on this server, yours or others. This includes the addition of CGI files, attempting to hack into other known accounts, attempting to bypass server security, or drawing cracker attention to served sites here. We protect our customers fiercely, and we prosecute. Our lawyers aren't very pretty when they're either angry or underfed. If you suspect something odd about your site, notify us immediately (please!).

Access by minors to your account under any circumstance is your responsibility, and their actions will also be your responsibility.

Always maintain a copy of your site material in some fashion, be it paper or electronic. We highly recommend working with designers who will provide all necessary files to you upon request. Expect to pay them for this service, for collecting or maintaining sites can be a time-intensive process, but the peace of mind is well worth the small amount you can expect to pay.

It is our policy that the client is ultimately responsible for data backup and that includes any generated via dynamic means. You have several methods to backup that dynamic data, among them frequent purging of the database as an exported file to your webspace, then downloaded to your machine, generating a backup email or tab-deliminated file of each transaction, or writing that data to a text file which is then downloaded on a regular basis. This is particularly important for ecommerce sites.

We backup several times per month as nothing more than a convenience for our clients in the event of a disaster, but you still have the ultimate responsibility.

Any and all software posted on your site should be tested for and free of any computer virus, trojan horse, worm or other naughty collection of code.

Prospective clients may be requested credit verification information under unusual circumstances, depending upon services requested.

RDUonline reserves the right to decline or cancel service for any reason without prior notice.

Discount and promotional programs are not retroactive and will be applied to the next billing cycle.

Conditions:

In adherence to our terms above, we also ask that you consider your site a public forum, and as such, please exercise appropriate tastes when presenting to the world. We do not exercise nor claim any editorial jurisdiction over sites other than our terms as stated above. However, we do reserve the right to terminate any account at any time without prior notice nor refund should said account conduct illegal activities, use our facilities for SPAM, warez (pirated software), or pornographic/orjectionable material.

We reserve the right to modify our terms upon notification to existing clients when necessary.

We reserve the right to make scheduled maintenance of our services on an as-needed basis during the hours of 11 pm and 7 am without notice, or under emergency service at all other times. This service may or may not render some or all services unavailable for short periods of time. We apologize in advance for any inconvenience this may bring you.

Information transmitted through our servers is not encrypted or confidential unless previously encoded by the user or part of our Secure Socket Layer eCommerce services. No email or attached files can be considered confidential and we reserve the right to monitor any user's activities or transmissions when deemed necessary for providing proper service and/or to protect the rights and property of RDUonline or its parent company. We will not disclose any information about any User unless required to by court order, subpoena, other legal request, or upon the advice of counsel.

You, the account owner, agree to indemnify and hold without harm RDUonline, its owners, parent company, employees, or agents from any and all claims, damages, expenses, and liabilities resulting from any use of an account, whether authorized or not.

Please restrict POP/SMTP account logins to no more than 20 per hour or 100 per day.

If you do not agree to these terms and conditions, please notify your account representative or us immediately in writing to deactivate your account. Failure to notify us constitutes acceptance of these terms. We cannot supply information regarding account billing as we are not privy to that information ourselves. Please contact your account representative with those questions.

Payment information.

We accept credit card payments (Visa, MasterCard, American Express & Discover cards), personal check, company check, bank check and money order, made out to our parent company: After Hours.

RDUonline takes your website security seriously. We have gone to great lengths to offer a web hosting service which is well protected against hacker intrusion. No site can be offered to the public and be completely safe, but we feel our measures stack up well against the threat of unwelcome intrusion. Hosting on a Macintosh is the first, and best defense against most hackers intent on corrupting your website or data theft. Be vigilant and not careless with your website identification and passwords (don't leave them available to the general public, family, friends, or anyone without a need to know will help, too.) Did you know that most of the world's computer crime is due in part to carelessness on the part of the computer owner or user!

The following articles contain information backing up our claim that Macs are better than your alternatives when it comes to web hosting. We invite you to think: Macintosh. According to the World Wide Web Consortium (the "governing body of the web" if there is such as thing) states "The safest Web site is a bare-bones Macintosh running a bare-bones Web server." (for a link to this document, click HERE, http://www.w3.org/Security/faq/wwwsf1.html ). View an assessment of successful hacking attempts (including divulged password access which is the only way to get into a Mac) here.

Commercial retail sites which may handle sensitive information such as credit cards can take advantage of our Secure Socket Layers certificate service.

Security. Let's take a reality check here. Any computer on the Web can be broken into given enough time. But most hackers will give up when facing a Mac -- just because with Windows XP servers, there's so much easier picking available. And due to how the Mac works, there is only one way into a Mac. This limits the damage done to only the subdirectory or account penetrated. We've taken extensive measures to create a hack-proof site, using much of the same software and hardware the U.S. Military adopted after their NT-based websites were brought down by hackers in the summer of 1999 (for more on this story, click HERE, http://www.dtic.mil/armylink/news/Sep1999/a19990901hacker.html ). Security matters. Whether you are simply a company looking to have a web presence for advertising and PR, or if you wish to sell on the Web -- you need to know your information is as tamper-proof as possible.

Web page hacker arrested, government sites becoming more secure

by Sgt. 1st Class Connie E. Dickey
WASHINGTON (Army News Service, Sept. 1, 1999) - Working from information provided by the U.S. Army's Criminal Investigation Command, FBI agents arrested a 19-year-old Wisconsin man Aug. 30 for malicious altering of a U.S. Army Web page.
The agents identified the Green Bay man as the co-founder of a hacker organization known as "Global Hell."

The arrest capped a two-month investigation led by Army CID agents, after an unidentified intruder gained illegal access to the Army Home Page June 28 and modified its contents. The intruder also gained access to an unclassified Army network and removed and modified computer files to prevent detection.

Since the case is still ongoing, Christopher Unger, web site administrator for the Army Home Page, didn't want to talk about specifics of what the hacker did to the web page or what the Army is doing to protect its sites from future hackers. However, he said the Army has moved its web sites to a more secure platform. The Army had been using Windows NT and is currently using Mac OS servers running WebSTAR web server software for its home page web site.
Unger said the reason for choosing this particular server and software is that according to the World Wide Web Consortium, it is more secure than its counterparts. According to the Consortium's published reports on its findings, Macintosh does not have a command shell, and because it does not allow remote logins, it is more secure than other platforms. The report also said the Consortium has found no specific security problems in either the software or the server.
The Consortium is a worldwide group of representatives from more than 350 organizations that provide the infrastructure for a global interoperable World Wide Web. Membership is open to any organization.

"Government networks are inviting to hackers because of their high profile," Unger said. However, the Department of Defense is laying the groundwork now for more secure Internet sites that will prevent unauthorized access to information, he said.
(Editor's note: Some information was provided by the U.S. Army Criminal Investigation Command.)

The World Wide Web Security FAQ (from the W3C website)

------

DISCLAIMER

This information is provided by Lincoln Stein (lstein@cshl.org). The World Wide Web Consortium (W3C) hosts this document as a service to the Web Community; however, it does not endorse its contents. For further information, please contact Lincoln Stein directly.

------

General Questions

Q1: What's to worry about?

Unfortunately, there's a lot to worry about. There are security risks that affect Web servers, the local area networks that host Web sites, and even innocent users of Web browsers.
The risks are most severe from the Webmaster's perspective. The moment you install a Web server at your site, you've opened a window into your local network that the entire Internet can peer through. Most visitors are content to window shop, but a few will try to to peek at things you don't intend for public consumption. Others, not content with looking without touching, will attempt to force the window open and crawl in. The results can range from the merely embarassing, for instance the discovery one morning that your site's home page has been replaced by an obscene parody, to the damaging, for example the theft of your entire database of customer information.

It's a maxim in system security circles that buggy software opens up security holes. It's a maxim in software development circles that large, complex programs contain bugs. Unfortunately, Web servers are large, complex programs that can (and in some cases have been proven to) contain security holes. Furthermore, the open architecture of Web servers allows arbitrary CGI scripts to be executed on the server's side of the connection in response to remote requests. Any CGI script installed at your site may contain bugs, and every such bug is a potential security hole.
From the point of view of the network administrator, a Web server represents yet another potential hole in your local network's security. The general goal of network security is to keep strangers out. Yet the point of a Web site is to provide the world with controlled access to your network. Drawing the line can be difficult. A poorly configured Web server can punch a hole in the most carefully designed firewall system. A poorly configured firewall can make a Web site impossible to use. Things get particularly complicated in an intranet environment, where the Web server must typically be configured to recognize and authenticate various groups of users, each with distinct access privileges.

To the end-user, Web surfing feels both safe and anonymous. It's not. Active content, such as ActiveX controls and Java applets, introduces the possibility that Web browsing will introduce viruses or other malicious software into the user's system. Active content also has implications for the network administrator, insofar as Web browsers provide a pathway for malicious software to bypass the firewall system and enter the local area network. Even without active content, the very act of browsing leaves an electronic record of the user's surfing history, from which unscrupulous individuals can reconstruct a very accurate profile of the user's tastes and habits.
Finally, both end-users and Web administrators need to worry about the confidentiality of the data transmitted across the Web. The TCP/IP protocol was not designed with security in mind; hence it is vulnerable to network eavesdropping. When confidential documents are transmitted from the Web server to the browser, or when the end-user sends private information back to the server inside a fill-out form, someone may be listening in.

------

Q2: Exactly what security risks are we talking about?

There are basically three overlapping types of risk:

1. Bugs or misconfiguration problems in the Web server that allow unauthorized remote users to:
* Steal confidential documents not intended for their eyes.
* Execute commands on the server host machine, allowing them to modify the system.
* Gain information about the Web server's host machine that will allow them to break into the system.
* Launch denial-of-service attacks, rendering the machine temporarily unusable.

2. Browser-side risks, including:
* Active content that crashes the browser, damages the user's system, breaches the user's privacy, or merely creates an annoyance.
* The misuse of personal information knowingly or unkowingly provided by the end-user.

3. Interception of network data sent from browser to server or vice versa via network eavesdropping. Eavesdroppers can operate from any point on the pathway between browser and server including:
* The network on the browser's side of the connection.
* The network on the server's side of the connection (including intranets).
* The end-user's Internet service provider (ISP).
* The server's ISP.
* Either ISPs' regional access provider.

It's important to realize that "secure" browsers and servers are only designed to protect confidential information against network eavesdropping. Without system security on both browser and server sides, confidential documents are vulnerable to interception.
Protecting against network eavesdropping and system security are the subject of sections 1 to 5 of this document. Client-side security is covered in sections 6 and 7. Section 8 deals with security alerts for specific Web servers.

------

Q3: Are some operating systems more secure to use as platforms for Web servers than others?

The answer is yes, although the Unix and NT communities may not like to hear it. In general, the more powerful and flexible the operating system, the more open it is for attack through its Web (and other) servers.
Unix systems, with their large number of built-in servers, services, scripting languages, and interpreters, are particularly vulnerable to attack because there are simply so many portals of entry for hackers to exploit. Less capable systems, such as Macintoshes and special-purpose Web server boxes, are less easy to exploit. The safest Web site is a bare-bones Macintosh running a bare-bones Web server. See Q84 for details.

In the real world, of course, many sites will want to run a Windows NT or Unix server in order to gain the performance advantage of a multitasking operating system and the benefits of database and middleware connectivity . Security holes have been found in both Unix and Windows NT server systems, and new security holes are being found on a regular basis. On the whole Windows NT systems seem to be more vulnerable at the current time, partly the OS is relatively new and the big bugs haven't been shaken out, and partly because the NT file system and user account system are highly complex and difficult to configure correctly.
If you have configured your system correctly and are compulsive about applying your vendor's security patches promptly, a typical Unix system will be more secure than a typical NT system. However, you also have to factor in the experience of the people running the server host and software. A Unix system administered by a novice system administrator will be far less secure than an NT system set up by a seasoned Windows NT system administrator.

-------

Q4: Are some Web server software programs more secure than others?

Again, the answer is yes, although it would be foolhardy to give specific recommendations on this point. As a rule of thumb, the more features a server offers, the more likely it is to contain security holes. Simple servers that do little more than make static files available for requests are probably safer than complex servers that offer such features as on-the-fly directory listings, CGI script execution, server-side include processing, and scripted error handling.

Version 1.3 of NCSA's Unix server contains a serious known security hole. Discovered in March of 1995, this hole allows outsiders to execute arbitrary commands on the server host. If you have a version 1.3 httpd binary whose creation date is earlier than March 1995 don't use it! Replace it with the patched 1.3 server (available at http://hoohoo.ncsa.uiuc.edu/) or with version 1.4 or higher (available at the same site). The Apache plug-in replacement for NCSA ( http://www.hyperreal.com/apache/info.html) is also free of this bug.

Servers also vary in their ability to restrict browser access to individual documents or portions of the document tree. Some servers provide no restriction at all, while others allow you to restrict access to directories based on the IP address of the browser or to users who can provide the correct password. A few servers, primarily commercial ones (e.g. Netsite Commerce Server, Open Market), provide data encryption as well.

The WN server, by John Franks, deserves special mention in this regard because its design is distinctively different from other Web servers. While most servers take a permissive attitude to file distribution, allowing any document in the document root to be transferred unless it is specifically forbidden, WN takes a restrictive stance. The server will not transfer a file unless it has been explicitly placed on a list of allowed documents. On-the-fly directory listings and other "promiscuous" features are also disallowed. Information on WN's security features can be found in its online documentation at: http://hopf.math.nwu.edu/docs/security.html

A table comparing the features of a large number of commercial, freeware and public domain servers has been put together by the WebCompare site: http://www.webcompare.com/

------

Q5: Are CGI scripts insecure?

CGI scripts are a major source of security holes. Although the CGI (Common Gateway Interface) protocol is not inherently insecure, CGI scripts must be written with just as much care as the server itself. Unfortunately some scripts fall short of this standard and trusting Web administrators install them at their sites without realizing the problems.

------

Q6: Are server-side includes insecure?

Server side includes, snippets of server directives embedded in html documents, are another potential hole. A subset of the directives available in server-side includes instruct the server to execute arbitrary system commands and CGI scripts. Unless the author is aware of the potential problems it's easy to introduce unintentional side effects. Unfortunately, html files containing dangerous server-side includes are seductively easy to write.
Some servers, including Apache and NCSA, allow the Web master to selectively disable the types of includes that can execute arbitrary commands. See Q10 for more details.

------

Q7: What general security precautions should I take?

If you are a Webmaster, system administrator, or are otherwise involved with the administration of a network, the single most important step you can take to increase your site's security is to create a written security policy. This security policy should succinctly lay out your organization's policies with regard to:

* who is allowed to use the system
* when they are allowed to use it
* what they are allowed to do (different groups may be granted different levels of access)
* procedures for granting access to the system
* procedures for revoking access (e.g. when an employee leaves)
* what constitutes acceptable use of the system
* remote and local login methods
* system monitoring procedures
* protocols for responding to suspected security breaches

This policy need not be anything fancy. It need only be a succinct summary of how the information system work, reflecting your organization's technological and political realities. There are several benefits to having a written security policy:

1. You yourself will understand what is and is not permitted on the system. If you don't have a clear picture of what is permitted, you can never be sure when a violation has occurred.
2. Others in your organization will understand what the security policy is. The written policy raises the level of security consciousness, and provides a focal point for discussion.
3. The security policy serves as a requirements document against which technical solutions can be judged. This helps guard against the "buy first, ask questions later" syndrome.
4. The policy may help bolster your legal case should you ever need to prosecute for a security violation.

More suggestions for formulating a security policy can be found in the general Internet security reference works listed at the end of this document.
For Web servers running on Unix and NT systems, here are some general security precautions to take:

1. Limit the number of login accounts available on the machine. Delete inactive users.

2. Make sure that people with login privileges choose good passwords. The Crack program will help you detect poorly-chosen passwords: ftp://ftp.cert.org/pub/tools/crack/

3. Turn off unused services. For example, if you don't need to run FTP on the Web server host, get rid of the ftp software. Likewise for tftp, sendmail, gopher, NIS (network information services) clients, NFS (networked file system), finger, systat, and anything else that might be hanging around. Check the file /etc/inetd.conf (Unix) or Service Manager for a list of servers that may be lurking. Deactivate any that you don't use.

4. Remove shells and interpreters that you don't absolutely need. For example, if you don't run any Perl-based CGI scripts, remove the Perl interpreter.

5. Check both the system and Web logs regularly for suspicious activity. The program Tripwire (Unix), and Internet Security Scanner (Unix & NT) are helpful for detecting this type of activity:

Tripwire ftp://coast.cs.purdue.edu/pub/COAST/Tripwire/

Internet Security Scanner http://www.iss.net More on scanning Web logs for suspicious activity below.

6. Make sure that permissions are set correctly on system files, to discourage tampering. On Unix systems, the program COPS is useful for this:
ftp://ftp.cert.org/pub/tools/cops/
On Windows NT, give Midwestern Commerce's Administrator Assistant Toolkit a try:
http://www.ntsecurity.com

Be alert to the possibility that a _local_ user can accidentally make a change to the Web server configuration file or the document tree that opens up a security hole. You should set file permissions in the document and server root directories such that only trusted local users can make changes. Many sites create a "www" group to which trusted Web authors are added. The document root is made writable only by members of this group. To increase security further, the server root where vital configuration files are kept, is made writable only by the official Web administrator. Many sites create a "www" user for this purpose.

------

Q8: Where can I learn more about general network security measures?

Good books to get include:

* Unix System Security: A Guide for Users and System Administrators, by David Curry
* Practical Unix Security, by Simson Garfinkel and Gene Spafford
* Windows NT Security Guide, by Stephan Sutton.

A source of timely information, including the discovery of new security holes, are the CERT Coordination Center advisories, posted to the newsgroup comp.security.announce, and archived at:
ftp://ftp.cert.org/pub/cert_advisories/
A mailing list devoted specifically to issues of WWW security is maintained by the IETF Web Transaction Security Working Group. To subscribe, send e-mail to www-security-request@nsmx.rutgers.edu. In the body text of the message write:
SUBSCRIBE www-security your_email_address
A series of security FAQs is mainted by Internet Security Systems, Inc. The FAQs can be found at:
http://www.iss.net/sec_info/addsec.html
The main WWW FAQ also contains questions and answers relevant to Web security, such as log file management and sources of server software. The most recent version of this FAQ can be found at:
http://www.boutell.com/faq/

------
Lincoln D. Stein (lstein@cshl.org)

Last modified: Mon Sep 13 13:51:16 EDT 1999

A Note from RDUonline: the above was gleened from Mr. Stein's information treatese on web server security. Most of this information has no direct bearing on our host clients, but we feel that it is important for you, our clients, to know that web server security matters greatly to us. You can help keep your information secure and free of abuse by following some simple guidelines:

1) Never release your log on or email identification or passwords to anyone for any reason. If you receive a phone call from someone claiming to be a representative of your ISP, hosting agent or RDUonline, and they request logon or password information, rest assured that they are NOT a representative of your ISP us, or our affiliates!!! We do not release such information to anyone except the customer. Heck, we won't even fax or email that information in any form to any location. We're sure your ISP would be equally careful with your personal information. We will release your information to you directly in person, or via US Mail to the address we have for you on record, as part of your copy of your contract.

Do not leave your contract or account access information laying out in the open, or in an unsecured location. Protecting your privacy is up to you, first.

2) The only exceptions we can imagine for the above rule #1 would be to release your ftp logon information for uploading your website information to our servers. If you change designers, contact us to change your password(s). We trust all of our affiliates, but your security is your responsibility -- share it wisely. Don't be complacent.

3) There are methods which can take down ANY webserver on the web. Sometimes, the best defense is to leave as little information available to potential hackers as possible. The attention you want drawn to you is for information distribution, marketing or sales. Keep that your focus.

4) If our servers are ever shut down (or hacked by broken passwords), we will prosecute. Your contract stipluates that you will lend what assistance you can to the identification and prosecution of any individual who attempts to breech a site served by RDUonline. Let's protect hapless hackers from themselves by not divulging information which may lead to them attempting to attack the service, and suffering the consequences.