Back from a summer hiatus. Reminder: I am available for short-term consulting, security training of all sorts, and product analysis and review. Drop me a note. -- Fred

NetSec Letter #20, 1 September 2002

The Need for Web Server Security

Fred Avolio, Avolio Consulting, Inc.,

A few months ago I was a guest lecturer at Dnepropetrovsk National University in Ukraine. For an international economics class, my topic was "The Need for Security in an Internet-affected economy." One of the students asked, "Is it so important to worry about security at this time? Very few businesses [in Ukraine] are on the Internet."

This was a good question. In Ukraine, connections to the Internet are usually slow (dial-up on noisy phone lines). Most companies are *not* connected to the Internet. In fact, Internet use in Ukraine today is similar to Internet use in the United States in 1992.

Should they care about security, or wait until there is more business and more targets?

Measuring Risk

Getting a handle on "risk" is sometimes difficult. We cannot ever measure it exactly. This is okay. There is no such thing as *perfect* security. We therefore have the freedom to "fudge."

Of course, we also have to define risk. There are many definitions for risk, and the related terms threat, vulnerability, and cost. I use an equation developed by TruSecure Corporation ( ). [Disclosure: TruSecure Corp. is a client of Avolio Consulting, Inc.]

Risk = Threat * Vulnerability * EventCost.

Threat is the likelihood that a security event will happen in a given time span or at a particular rate. And out of all the possible threats, there is a smaller number of those *someone* knows about, and an even smaller number *you* know about.

A given target is either vulnerable or not to a particular well-defined threat, or variably vulnerable to a *class of threats*. There may be millions of vulnerabilities on a network/system. The total that will *ever* be discovered is in the thousands. The total that will ever be exploited is in the tens.

The total sum of all ramifications of a security event is called EventCost. This might include lost sales, loss of customer confidence, and over-time spent performing forensics and triage.

So, if any of Threat, Vulnerability, or EventCost is zero, the Risk is zero. A risk analysis, then, requires us to first find if any of these are zero, and if none are, to try to determine the actual or estimated values.

10 steps to better server security

  1. Remove all user accounts from servers. Only system administrators should have access to network servers. And, if you can, limit administrator access by IP address.
  2. Require strong user authentication -- tokens, biometrics, or certificates -- for administrator access. (Get rid of reusable passwords.)
  3. Look at the function of the server and remove any unnecessary daemons (network server processes). A web server, for example, should have 2: one serving http, and another serving ssl. It should not be running a DNS daemon. (It can still *use* DNS.) It should not run an e-mail daemon. An e-mail server system should have an SMTP daemon and, perhaps, a POP3 daemon. Nothing else is required. Disable all other daemons. This is minimalism. Minimalism is good.
  4. Verify the security state of the server by using vulnerability assessment tools. Make sure the way you *think* things are matches the way they *really* are (and make sure it matches what your security policy *says* they are). For more on this see NetSec letter #18 ( ).
  5. Make use of host-based intrusion detection systems, also, if you can afford them. Antivirus software on e-mail servers is in this category, as are burglar alarms, such as Tripwire ( and ).
  6. Monitor security mailing lists. Pick one of the free e-mail services. Also, don't forget vendor-specific alert lists. Get CERT ( ) alerts as well. Act on them. It is useless to be notified that there is a hot vulnerability in Microsoft IIS if you do not act on the information.
  7. Remove unneeded tools from your servers. This includes unused CGI scripts on web servers, especially in an "examples" directory. Squeamish? Then do this one item at a time and wait to see what happens. (I am serious.)
  8. Limit access by IP network address space, perhaps with a firewall. Map out what systems or network addresses should be connected and deny access to all others.
  9. Filter connections to the server. If we did what #3, above, said to do, match this with rules in a filtering router or firewall. Only permit traffic that *must be* permitted.
  10. Use firewall filtering rules to look for traffic that should never be seen to and from your servers. (This was suggested by Marcus Ranum in the June 2000 issue of *;login*.) Should there be SMTP connections coming from your web server to the Internet? What if it tries to initiates a TELNET to the inside network? Maybe you have a security event.

Back to the Student's Question

Like a new kid moving into a tough neighborhood who gets beaten up in his first day, When the Republic of Chile's first national ISP came on line, said, "Hola," the Internet-at-large launched massive attacks, crashing systems, and bringing the connections down. Welcome to the neighborhood, Chileans.

I pointed out a few things to the students. When I first visited Ukraine (another, but different training trip -- ), we were glad to have electricity (and did not always have running water, or heat). Now, when I go there I expect to be able to access my email, either from a friend's home PC, or from an "Internet Cafe" (sometimes one in the hotel). I asked how many had Internet access, either from the university, or home, or from a cafe? Most of the students did. I demonstrated in discussion that, although the number of people and businesses with Internet access is much less than in the US, the growth curve is much steeper than it was in the US. And, of course, the likelihood of an attack -- and so the risk -- is not a function of the number of targets *in Ukraine*. It is a function of the number of potential attackers on the Internet. Welcome to the neighborhood.

Promotions, Self and Otherwise

I've added two recent columns that I wrote for WatchGuard ( ) to my website: "Five 'Must Have' Defenses for Mobile Computer Users" ( ) and "Wireless at Home" ( )

I also wrote a column on wireless for the August 2002 *Information Security Magazine*. Read "The Real Deal on Wireless" at .

September 2002: I'm teaching 2 courses at Networld+Interop. Monday, September 9, I am teaching the full day "VPN Day: Fundamentals" with security consultant and buddy Dave Piscitello. (Dave and Joel Snyder are teaching "VPN Day: Design and Deployment" on September 10.) September 11, I will teach "Firewall Best Practices." For more information, check  my calendar .