Conference noted::seal

Well, what do they want to trust?  I have a customer (with a very
special configuration, incidentally) for whom it is reasonable to
trust a very few "red net" addresses.  They have a custom policy 
on the telnet/ftp proxies that permits those addresses inbound
without authentication.

I also have customers who use inbound access with re-usable password
authentication, where it is an "internal" firewall, so that the red
net is somewhat trusted.

Both these can be done with V2, though the second one requires 
editing outside the GUI ...

T

Groovy. Since I don't have a firewall or any documentation handy, could you give 
a poor consultant an implementation hint, please?

PJDM

hi

If someone setup an seminar that deals customising AFW, mail, dns I can 
make a speech (I have done lots of customysing) there and learn also my self !

	
Marko

Marko,

I have two suggestions:

1) Use this notesfile to write-up what you've done by way
of customisations.  Several of us have done this already,
and you would be contributing to that "pool of knowledge".
Consider this notesfile the communications medium for the
"Self Help Group" that is Digital's Firewall Consultants ...

2) Write up what you've customised (preferably as html page(s),
though any other format is acceptable!) and mail it to me.  I
will then post it on the "Firewall Hints and Tips" WWW Site at
http://sector.gmt.dec.com/firewall.

Please don't think (any of you!) that you have to be an expert
to contribute to either place.  I'm not an expert on UNIX at
all.  I know what I know!  That's all ...

In addition, either place will take write-ups that are simply
lists of points that have to be addressed for a particular
customisation, or they will take detailed polished write-ups,
or they will take anything in between.

As I've said many times before, as consultants we are not in
the game of selling hardware OR software.  We are in the game
of building solutions to customers' requirements, and we use
the firewall product(s) as one part of the tool kit.  We
must get smarter about sharing the other bits and pieces that
we use ...

T

re .2:

I proposed two posible solutions to your "requirement":

1) Allowing limited inbound access

Set up a red usergroup through the GUI that lists the
allowed set of machines on the outside that can connect
inbound - specify user unknown for each of them.

(Optionally: set up a blue servergroup that contains all
the internal machines that can be accessed inbound without
authentication.)

Set up a custom security policy through the GUI for ftp
and/or telnet (and/or in V3 WWW) that permits that red
usergroup access to all servers (or to the blue server-
group).

... and you have inbound unauthenticated access ...



2) Inbound re-usable passwords

Set up the security policy on ftp and/or telnet (and/or
in V3 WWW) so that inbound authenticated access is permitted.

Set up one or more users, specifying re-usable password
for outbound authentication (note this is required!) and
any other method for inbound access - I suggest that you specify
a mechanism that won't be used at all.

Manually edit the file /usr/dfws/config/auth-keyfile.  This
file contains one record for each user defined on the firewall.
The last two fields of the record indicate the authentication
type for inbound and outbound authentication respectively - the
field separator in the record is colon (:).  You will find that
the second of these - the last field in the record - is "pw", 
while the other one is something else - "snk" if you specified
SNK for inbound authentication in the GUI, ONPW for one-time
password, RWW for Racal Watchword, etc.  Edit the record so that
the two fields both say "pw" - the record should end ":pw:pw:"
(without the quotes!).

... and you have inbound reusable password authentication.



Simple, isn't it!  Do be sure to explain the security risks
involved to your customer.  In particular, if you are trusting
external IP addresses, then you should be aware of the risk of
IP spoofing of a trusted host - a filtering router outside the
subnet including the trusted host may be able to help here - 
and with reusable passwords, you are vulnerable to people
sniffing the userid and password on the external network - 
once again, network design may be able to reduce this risk.


T

    If you only require one external host ('redserver') to telnet to an
    internal machine ('blueserver'):
    
    Use the generic proxy to establish a service 'intelnet' on say port
    1001. Point the internal side to 'blueserver' port 23.
    
    You can then get in by doing 'telnet firewall 1001' on 'redserver'.
    
    Bj�rn