Conference noted::seal

There is a major problem with the reports in AFWU V2.x.
They are even less complete than those in DFW V1.0!  I 
have fed back on this to Engineering, and I sincerely
hope that the reports are enhanced in V3.

In particular, the following things are currently "wrong":

1) The sort by user reports are useless for unauthenticated
access.  They should be sorted and summarized by address.

2) The mail reports are useless except as an indication of 
the total amount of data transferred.  They should be 
processed by sender and recipient.  (Note: I have made 
available a perl script that will generate "sensible" reports
from the mail.log file ...)

3) There are no "exception reports" - customers want to know
how many unauthorised attempts there were on the firewall
in the last week/month/etc, and what types.

4) There is no useful WWW report on the servers that were
contacted.

The raw information for all of the above is already
contained in the logfiles.  It is possible, therefore, to
produce the required reports via perl scripts or whatever.
However, they should be there within the product, and I
am hoping for improvements in V3 ...

Very sadly, I have to say that the issue with the reporting
in AFWU V2.x is the same as Digital used to have ten years
ago with a great many of its products, but which I haven't
seen for a while.  Engineering groups tend to produce lots
of "nice features" but they don't have a good view of what
the customer actually wants, or how the customer will use
the products.  I think this is the issue here.  There are
"nice reports" produced by the products, but they are
simple not the reports that the customers need, in my
experience.

Lest anyone think I am simply criticising Engineering, let
me say one more thing:  this criticism is directed equally
at Engineering AND at the firewall consultants within
Digital, and to a lesser extent at sales within Digital.
It is true that "Engineering should find out what the
customer wants", but it must also be true that we - the
firewall consultants - are not passing on the customers
requirements to Engineering.  We are the people who talk
to customers day in, day out, about firewalls, and we
see how they use them.  We have the very best requirements
information that we should pass on to Engineering, and I
don't believe we have done this well enough.

... end of lecture!

T

Re: .0:

>The FTP reports sorted by size of data or user have local host as "localhost", 
>rather than the client doing the FTPing.

I think what you are seeing here are actually web browsers going to ftp 
urls.  The wwwproxy passes off the ftp urls to ftpxd (to keep someone 
from bypassing the ftp security policy with a web browser) so to the 
ftpxd relay, the wwwproxy looks like 'localhost'.  If you ftp directly 
through the firewall with an ftp client, it should show the proper host 
is the ACLACCEPTCONN line in the ftpxd log.

I don't care (in this case) what the mechanisms are, all I can see is that users 
are going through the firewall without being logged.

PJDM

Re .-1: Well, errr, that's not QUITE the situation, is it ...

They are being logged, but not in a single place.  Anyone
accessing an ftp URL will be logged in the wwwproxy.log file,
whereas anyone going direct to the ftp proxy will be logged 
in the ftpxd.log file...

Is this sensible, helpful, useful?  No.

T

I agree, it's not quite the situation, but the logs that are produced by the 
firewall reporting mechanism aren't showing the users. What's the point of 
having a reporting mechanism that doesn't report anything useful?

As you say: sensible, helpful, useful?  No.

PJDM