On Wed, 10 Mar 1999 [EMAIL PROTECTED] wrote:
> My thanks to all the members of the list who answered my questions about audit
> issues privately! Thank you! You are a great resource. I am the auditor not the
> person installing the firewall!
You should really consider thanking the people who answered publicly too.
I've read and re-read the entire thread, and thought quite a bit about the
audits I've had done on my systems and the audits I've done on others'
systems. If you intend to *really* audit a firewall at this point, then I
think you're doing a disservice to the auditee *especially* if it is intended
to be a check or balance to the administrator.
The audits I've had from professional IT auditors who didn't know the
environment have been more than amusing. They've basicly ended up being
narrated self-audits with long pauses for explainations. Since I
self-audit before I go live, and periodicly after that, they've been
a complete waste of my time. My VP wasn't happy the last time an auditor
presented him with a report and said auditor asked me in to explain the
report (since it was rather obvious that I was using the auditor to get
behaviour changes from the organization that I wanted.)
It seems, at least from your posts that you've got a checklist of things
to look at, but you don't know why they're there. At best that means
that you've got no way to evaluate a class of vulnerability, and at worst
it means that you'll have real difficulty spotting anything that's
half-creative.
*Lots* of administrators create back doors. I've had some tell me that I
was insanely stupid for not having any in the systems I administer. If
discovering such things is supposed to be in the scope of your audit, then
once again you're doing the auditee a great disservice. It is trivially
easy for an administrator to hide things from all but the most thorough
of auditors. If you can't do a vulnerability assessment from the ground
up, including either single-user mode boots and checksums against
shipping media, hands-on, then perhaps you can (for the sake of the
doubters at least) illuminate us as to the value such an audit brings the
company which is paying for it?
There was a really good thread either here or on firewall-wizards about
auditor competency (with real content, not just flames about the big
six). Someone (perhaps Bennett?) had some very good points about
auditors, and it's worth a search to find.
If I saw an auditor coming in with questions who couldn't explain to me
in great detail why they were asking the questions, and who had zero
administrative experience with the platforms included in my firewalls,
I'd probably give them a root shell in a chroot'd environment, set up a
nameserver record that pointed to loopback for external scans, and amuse
myself for hours while they "checked everything."
Firewalls and firewalling is necessarily complex, and a real audit of
such systems requires in-depth _platform specific_ experience and knowledge.
There are professional INFOSEC auditors who can set up sniffers and tell
you if your Solaris Ethernet drivers are leaking information like
passwords because they don't clear frames. They can tell you that an
administrator has set up a trojaned nameserver for telnet over UDP
access, and more importantly they can *educate* an administrator on
_specific things_ they can do to improve the security of their systems.
If you'd like to turn the balance, here are some tasks you should
complete *before* trying to do an audit:
1. Correctly install the same version of the OS as the victim and
generate checksums of everything. Let it run for a day, and
generate new checksums. Find and explain the differences in files.
2. Get the published vendor patches for said OS and write a small
explaination of on security, or if there is no security value,
why the patch doesn't provide any. Now you can recommend some
useful improvements to your victim.
3. Install the same class of firewall on the above system and do
the same checksum exercise. Add a user, service, or network
device, repeat checksum exercise. Now you've got some idea of
what normal change is on the platform you're going to audit. This is
a very good thing. You're also capable of helping your victim
understand the same, this is even better.
4. Obtain and build lsof. Run it on your firewall system, and account for
every open filehandle. Especially the sockets.
5. Change things until lsof shows only open filehandles that you can
explain a direct need for. Do a ps (-eaf || -aux depending on flavor),
account for each process. Get it down to only the processes you can
show a direct need for. At this point, you should already be able
to add some *real* value to the victim.
8. Read _Practical Unix Security_ and search the Web for "securing Unix"
documents. Compare your prior work with their contents. Now you've
got an idea of what the OS is up against, what the firewall needs to
protect for, and how to secure a Unix system. This puts you into
a good position.
7. Get the protocol specifications for telnet, ftp and http. Analyze
them for vulnerabilities. Document your analysis. *Not until after
you're done with the documentation*, search for known vulnerabilities
in each service. Reconcile the difference in your analysis and the
proven vulnerabilities. Now repeat your analysis for rsh, ident,
and ssh. By this time, you should have a clue as to why .rhost
files are bad, but the r* protocols are worse. Also, you should
be able to understand that the presence of a .rhost file isn't
automatically indicitave of a vulnerability. This is a valuable
clue that your checklist won't give out by itself.
8. Now that you've set up and run a firewall for 3-4 days, done
protocol vulnerability analysis, analysis of known exploits,
OS updates and read a great deal of information, you're ready to
start looking at the firewalling issues.
9. Get nmap. Run it against your firewall. Run it against a
client PC. Turn off the firewall, start up a Web server and
the original OS services and run it again. Analyze the results.
Find out what they mean.
10. Find out about the internal routing protocols in general use, and
analyze their vulnerabilities. Do the same for external routing
protocols. Contrast the protection mechanisms built into external
and internal routing protocols.
11. Set up a sniffer and capture real internet traffic. Provide an
analysis of it, both function and vulnerability.
12. Document what your auditing doesn't cover. Find out what it takes to
get the victim to sign paper that explains this.
If you get that far, the next steps will fall quite easily. If you
don't, then you will continue to provide less-than-ideal value. If
you're signing audit reports without such information, I'd make sure that
my employment contract contained a bullet-proof clause about my employer
covering any legal fees and taking culpability for anything that wasn't
covered in my training. Most companies use the "bad apple" defense to
stop them from being sued by {customers, shareholders, employees}. If you
audited a company I invested in, and it was subsequently broken into, I know
what I'd be telling our lawyers.
Finally as a closing thought for the rest of the list, the same
conclusion as last time would seem to apply:
Make sure you can interview any auditors who come in to do your audits.
If you can't learn _real_useful_information_ from the auditor, then the
audit is a waste of time and more importantly perception. You're also still
generally held accountable for problems, so auditor problems are your
responsibility as well.
IOW: Audit your auditors.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
