As it says in the Bible in Hezekiah 5:10, “The one who sets the plan in motion, but verifies it not, is worse than a fool.”
Okay, you know that there’s no book of Hezekiah in the Bible. But, the statement is accurate, especially as it pertains to verifying the state of our security. And verification does not take an advanced science degree. (After teaching three classes for NASA Kennedy Space Center, I’ve shied away from saying, “not rocket science.”) All it takes is a plan and a tool.
Years ago, when I was in the firewalls business, I sent someone on an installation job. The customer was replacing a packet-filtering firewall with our more robust application gateway firewall. Unlike today, when everyone has detailed specific, up-to-date, and relevant policies, the customer did not have a security policy, besides the Primordial Security Policy (see NetSec Letter #17, http://www.avolio.com/columns/17-TheNefariousAny.html ). In the process of gathering firewall-specific policies, the installer asked, “Do you permit outbound FTP requests?” To which he got the reply, “No.” The installer sat down at a screen, typed in the FTP client command “ftp ftp.uu.net” and found indeed they did permit it. The written policy or the policy in the administrator’s head did not permit it, but the policy as implemented did. All it took to verify the policy was typing that one command.
Yes, it is really more involved than that. To be thorough, one would have to test every network port. To do that, you use an automated tool. There are commercial tools such as ISS’s Internet Security Scanner ( www.iss.net ) and freely available tools like NMAP ( www.nmap.org ) and Nessus (www.nessus.org ). You aim these scanners at the system or systems you wish to test, and pull the trigger. They automatically scan ports, look for known vulnerabilities.
A note of warning: running scanners against systems is considered a hostile act, and in some places is a criminal offense. Don’t think of scanning a computer that you don’t own, or for which you are not responsible, or that you have not been hired to scan.
Recently, my company took on the task of assessing the vulnerability of a web server. There is more to a vulnerability assessment than running a scanner and interpreting the results, but this is part of what we did. We used Nessus running on RedHat Linux and were very happy with the results.
First, we started with a plan, and so should you. All I mean by this is, know what you are testing. Know what should be there. If you are testing an FTP server and you find and FTP listener running on port 21, it is not a surprise. If you know you are testing a web server, and you were told that it is only used for web-related services, you should be surprised to find running listeners for SMTP (e-mail), and TELNET (terminal services).
Nessus can use NMAP, as well as other tools, for port scanning. It also comes with “plug-ins” — add-on tools that test and look for known vulnerabilities. There are 900 plug-ins in the database in 22 areas. It will produce a report, complete with graphs, lists of vulnerabilities found (classifying them as “high,” “serious,” “medium,” and “low”), and explanations of what it found. You may also specify how far Nessus will go in its testing. We set it in “safe” mode. This directs Nessus to not attempt to exploit indicated vulnerabilities.
In this installation, Nessus found ports running services we did not expect. The written and verbal information we received did not indicate they should be running. It also found a directory with example CGI scripts — some exploitable. It reported old, potentially vulnerable, versions of software, a potential vulnerability in a particular server, and server banner responses that give out too much information (for example, “220 ProFTPD 1.20pre1 Server”).
When the scanning was done, we were not finished. We still had to look at the report to see if it was accurate, and convey to the client what items were really important to deal with immediately, what might be false positives — with suggestions for “manual” verification steps, and what could be ignored — and why.
Verifying security is as important as initially planning and implementing it. And verification should be on going — a never-ending process. Our final recommendation to our client was this: “After addressing the concerns herein, scan the site monthly to see if the security posture changes, and account for those changes (or address them).”
There are 3 columns I wrote for WatchGuard Technologies I have not mentioned to you before. The first, from their “Foundations” series is “What Are Intrusion Detection Systems (IDS)?” at http://www.avolio.com/columns/WhatAreIDS.html . The second, “Security Tokens: Why Aren’t You Using Them?” at http://www.avolio.com/columns/tokens.html . And the third is “Basic IP Router Security” which you can find at http://www.avolio.com/columns/BasicRouterSecurity.html .
While doing some research for a class I am developing, I came across this short article from CIO Magazine: “How to make a firewall sandwich,” http://www.cio.com/archive/010102/sandwich.html .
Ron DuFresne has an interesting paper on his website entitled “Extrusion Detection Systems; the art of network monitoring.” You can find it at http://sysinfo.com/eds.html .
May 6 and 7 in Las Vegas, Dave Piscitello, Joel Snyder, and I will again be presenting our two VPN classes, “Introduction to VPNs” and “VPN Design and Deployment.” See http://www.avolio.com/calendar.html for information about these and other courses.
On May 30, I’m delivering the 11AM Keynote address at the eSecurity conference ( http://seminars.internet.com/esec/spring02/index.html ). The title is “Network Security: It’s Not Just for Security Guys Anymore.”
I’ll also be at CSI’s NetSec 2002 in San Francisco in June ( http://www.gocsi.com/ ). I’ll deliver a talk on wireless security, another on how to secure your web (or any other) server, and will teach my 2-day “Tools and Techniques” class ( http://www.avolio.com/courses/tools+techniques.html ).