-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

===============================================================================
>>                                                      CERT-NL, 01-Mar-2000 <<
>> All CERT-NL information has been moved to http://cert.surfnet.nl.  Links  <<
>> to CERT-NL information contained in this advisory are therefore outdated. <<
>>                                                                           <<
>> CERT-NL also has stopped the CERT-CC-Mirror service.  Due to this the     <<
>> links to the CERT-CC mirror are obsolete. Visit the CERT-CC site for the  <<
>> complete CERT-CC advisory texts:                     http://www.cert.org  <<
===============================================================================
===============================================================================
Security Advisory                                                       CERT-NL
===============================================================================
Author/Source : Don Stikvoort                               Index  : S-95-10.HP
Distribution  : World                                       Page   :          1
Classification: External                                    Version:          1
Subject       : SATAN / SANTA specifics for HP systems      Date   :  05-Apr-95
===============================================================================

By courtesy of Hewlett-Packard we received SATAN/SANTA information 
specific for HP systems, presented unabridged below.

=============================================================================

- - -------------------------------------------------------------------------
        HEWLETT-PACKARD SECURITY BULLETIN: #00026, 3 April 1995
                   ******** ADVISORY ONLY ********
- - -------------------------------------------------------------------------

Hewlett-Packard recommends that the information in the following
Security Bulletin should be acted upon as soon as possible. Hewlett-
Packard will not be liable for any consequences to any customer resulting
from customer's failure to fully implement instructions in this Security
Bulletin as soon as possible.


_______________________________________________________________________
ISSUE:    Release of SATAN program strengthens need for vigilant 
          system administration.
PLATFORM: All HP-UX systems
ACTIONS:  Install portmap patches specified below, and consider 
          advice discussed below.

PATCHES:
- - --------
ISSUE #1: Portmap permits forwarding of requests.
DAMAGE  : Remote users can gain unauthorized access to exported file
          systems.
SOLUTION: Apply patch PHNE_4879 (series 700/800, HP-UX 9.x), or
                      PHNE_5081 (series 300/400, HP-UX 9.0), or
                      PHNE_5156 (series 300/400, HP-UX 8.x)
          For 700/800, HP-UX 8.x, disable portmap.

ISSUE #2: ENHANCEMENT FOR HP-UX 9.x: Strengthen NIS authentication.
          NIS client/server enhancement for access control lists:
          Apply patch PHNE_4958 (series 700/800, HP-UX 9.x), or
                      PHNE_5081 (series 300/400, HP-UX 9.x)

ISSUE #3: NTP should not be used as the time source for HP-DCE/9000
          until further notice.
PLATFORM: All HP-UX systems
DAMAGE:   HP-DCE/9000 could require reconfiguration and re-installation.
ACTIONS:  Implement procedure discussed below before running SATAN.

_______________________________________________________________________


........................................................................
               Preparing Your HP-UX System for SATAN
                           Bob Kelley
                       bkelley@cup.hp.com
                  HP-UX Security Response Team


I. SATAN vs. HP-UX
   A. Writable FTP Home Directory
   B. Unprivileged NFS Access
   C. Unrestricted NFS Export 
   D. NIS Password File Access
   E. Portmap Forwarding
   F. TFTP File Access
   G. Remote Shell Access
   H. Vulnerability in rexd configuration
   I. Sendmail Vulnerabilities
   J. X Server Access
   K. NTP vulnerabilities and HP-DCE/9000

II. Additional Advice on Network Security 
   A. Fingerd
   B. Inetd and /usr/adm/inetd.sec
   C. Passwords
   D. Message Off 
   E. Denial of Service Attacks
   F. IP Spoofing
   G. RIP Updates
   H. Controlling Root Access
   I. DNS Searchlist / RFC 1535
   J. Vulnerability in rusersd configuration

III.  HP-UX Patch Information

IV.  HP SupportLine and HP Security Bulletins

V.   Report vulnerabilities to security-alert@hp.com

........................................................................



I. SATAN vs. HP-UX

The Hewlett-Packard HP-UX Security Response Team has tested 
beta version 0.50 of the Security Analysis Tool for Analyzing 
Networks (SATAN).  This advisory contains information 
based on our review of this pre-release version.  SATAN is
scheduled for release on April 5, 1995 at 14:00 GMT.

SATAN is a World Wide Web based tool that automates network
vulnerability testing and reporting. Documentation on SATAN can be 
found at:

    ftp://ftp.win.tue.nl/pub/security/satan_doc.tar.Z

SATAN gathers information about hosts or networks by remotely
examining network services.  It then generates a summary of the 
potential vulnerabilities discovered on those hosts.  In addition,
it offers a brief description of the vulnerabilities, and 
possible workarounds to those vulnerabilities.   At this time,
SATAN does not actively use these vulnerabilities to break into
the examined hosts.  

SATAN's construction provides a flexible framework for examining
network vulnerabilities and reporting test results.  Each time
SATAN is run, tests can be aimed at a single host, hosts on
a network, or hosts connected to the target host.  The testing
can expand exponentially to multiple "levels" away from the
target system or target network, adding many hosts to the list
of examined systems. 

SATAN is quite extensible: perl scripts designed to examine 
new network vulnerabilities can easily be added.  Combining 
this extensibility with the automation of quickly examining
many hosts allows SATAN to quickly discover vulnerable hosts.
 
The initial distribution of SATAN looks for about ten 
vulnerabilities.  As a result of publicity, it is likely
that additional tests will be added to SATAN.  The first
part of this advisory deals with the initial ten vulnerabilities
that SATAN targets:


A. Writable FTP Home Directory

   The ftpd man page provides appropriate recommendations
   for the permissions and ownership of all the sub-directories,
   but erroneously recommends that the ~ftp home directory be
   owned by ftp.  This allows an anonymous ftp user to change
   the permission on the ~ftp home directory, and control
   (read/modify/delete) any files owned by ftp in the
   ~ftp home directory.

   Make sure that the login shell of the ftp account is 
   de-activated by putting a '*' in the password field of the 
   /etc/passwd line, and referencing /bin/false as the login shell.

   Do not place a complete copy of /etc/passwd into
   ~ftp/etc to prevent distribution of the passwd file to
   hackers for cracking.  Instead, put '*' into the
   password part of each account in the ~ftp/etc/passwd file.
   Also, try to remove any accounts from the ~ftp/etc/passwd file
   of users that will not be using ftp.


B. Unprivileged NFS Access

   1. The problem

   rpc.mountd is usually started from /etc/netnfsrc by setting
   START_MOUNTD=1.  Starting rpc.mountd in this manner provides little 
   confidence in the originator of the mount RPC request.  An
   intruder could gain access to the exported file system.  If you
   are concerned about the security of exported file systems, 
   starting rpc.mountd from /etc/netnfsrc may be a vulnerability.

   2. Fixing the problem

   This vulnerability can be closed by only starting rpc.mountd 
   from /etc/inetd.conf and using /usr/adm/inetd.sec to control
   which clients may have access to the rpc.mountd program.

   Uncomment (or add) the rpc.mountd line in /etc/inetd.conf:

rpc dgram udp wait root /usr/etc/rpc.mountd 100005 1 rpc.mountd -e 

   The "-e" option causes rpc.mountd to exit after serving each
   RPC request, allowing inetd.sec to validate the authority of
   each RPC request.

   Be sure to start inetd with logging turned on (inetd -l) by
   modifying the /etc/netlinkrc line for inetd from:

[ -x /etc/inetd ]  &&  /etc/inetd  &&  /bin/echo "inetd  \c"

   to be:

[ -x /etc/inetd ]  &&  /etc/inetd -l &&  /bin/echo "inetd  \c"


   3. Limitations
  
   rpc.mountd handles each RPC request properly using inetd, as
   NFS is a stateless protocol that relies on RPC and UDP packets
   to deal with mount requests.  However, showmount (1M) cannot 
   be used when rpc.mountd is started from inetd since showmount 
   uses TCP to get information from rpc.mountd and inetd only 
   registers the udp port. 


C. Unrestricted NFS Export 

   Make sure all file exports specify an explicit list
   of clients or netgroups.  Empty host fields in netgroups
   are treated as wildcards, allowing any host to gain
   access to the file system, so be very careful when
   using these wildcards.

   Avoid exporting file systems with write capability if
   possible.  Avoid exporting file systems for root
   access if at all possible.


D. NIS Password File Access

   Make the NIS domain name a difficult one to guess,
   to prevent unauthorized ypbinds from binding to the 
   server.   Enforce good password selection when using 
   NIS to serve passwd maps, as it is quite likely that
   a hacker would be able to guess the domain name and
   get a copy of the /etc/passwd file to run a password 
   cracker against.

   An enhancement to HP-UX 9.x added an access control list to NIS.
   The /etc/securenets file is used by both clients and servers.
   On the NIS server, this file lists networks and hosts which may
   access NIS maps from this server.  On the NIS client, this file
   lists networks and hosts which may act as NIS servers when ypbind
   attempts to find a server.  

   To add the /etc/securenets functionality, install these patches: 

        9.x s700_800    PHNE_4879 
        9.x s300_400    PHNE_5081 


E. Portmap Forwarding

   This problem is fixed in most versions of HP-UX, when
   these patches are applied:

        9.x s700_800:   PHNE_4879
        9.x s300_400:   PHNE_5081
        8.x s300_400:   PHNE_5156

   Running portmap on a s700 or s800 with 8.x is vulnerable 
   to this attack.  If you are concerned with the security
   of such a system, disable portmap or upgrade to 9.x.


F. TFTP File Access

   HP's tftpd only allows access to the /usr/tftpdir directory
   and files in paths specified in the inetd.conf startup line.  

   Be careful not to offer access to directories containing
   vital information (/, /etc, or others), since tftp offers
   minimal protection. (The initial startup of tftpd is controlled
   by inetd which can control access via inetd.sec; however,
   once tftpd is running, no further validation is done by
   tftpd on new requests.)

   Make sure files in /usr/tftpdir cannot be overwritten
   by user tftp by turning write permissions off.  

   Make sure that the login shell of the tftp account is 
   de-activated by putting a '*' in the password field of the 
   /etc/passwd line, and referencing /bin/false as the login shell.


G. Remote Shell Access

   Using remsh (rsh), rlogin, or rcp permits a system to grant
   privileges without the user typing a password.  In a secure
   environment, behind a properly configured firewall, these
   services can be helpful.  Each user can create a .rhosts file
   to allow easy access to each host.  

   However, if your hosts are connected to an unsecure network 
   (say, the Internet), it is dangerous to grant privileges based 
   on a hostname and an IP address: you should consider disabling 
   these services by removing them from /etc/inetd.conf, or by 
   commenting them out in /etc/inetd.conf:

#login        stream tcp nowait root /etc/rlogind  rlogind 
#shell        stream tcp nowait root /etc/remshd   remshd  

   If you do decide to use them in an UNSECURE environment,
   consider using them WITHOUT .rhosts files, and WITHOUT 
   a /etc/hosts.equiv file.  As the super-user, you control
   the existance and contents of the /.rhosts and /etc/hosts.equiv
   files.  Furthermore, you can use the "-l" options to enforce
   a policy of preventing users from using .rhosts files.
 
   The remote shell daemon (remshd(1M), known as rshd on non-HP-UX 
   systems), offers a "-l" option to prevent authentication 
   based on the user's .rhosts file unless the user is the
   super-user.  Rlogind(1M) also offers a "-l" option.  Both 
   of these services are started from inetd, so you can add the
   "-l" option to their entries in /etc/inetd.conf:

login        stream tcp nowait root /etc/rlogind  rlogind -l
shell        stream tcp nowait root /etc/remshd   remshd -l

   In HP-UX, "+::" in the /etc/passwd file indicates a switch 
   to the NIS map.  It will NOT allow a login as user "+", so you 
   should NOT put "+:*:" in these files.  In HP-UX, "+:*:" indicates 
   that the NIS map should be consulted, but that all NIS accounts 
   should be de-activated!

   A '+' in the /etc/hosts.equiv file is a wildcard that indicates 
   that any remote host will be approved for access.  So, do NOT
   put a '+' in /etc/hosts.equiv.

   A '+ +' in /.rhosts (or any .rhosts) indicates that any remote
   user is approved for access.  So, do NOT put a '+ +' in the 
   /.rhosts file or in any .rhosts file.

   For maximum security, do not list user names in /etc/hosts.equiv:
   only list system names.

   Finally, remember to only use .rhosts or hosts.equiv files in a 
   trusted environment, behind a firewall.  


H. Vulnerability in rexd configuration

   1. The problem

   The default setting for rexd in the /etc/inetd.conf file is
   as follows:

#rpc  stream tcp  nowait  root  /usr/etc/rpc.rexd  100017  1 rpc.rexd

   If you uncomment this line to enable rexd, an intruder can
   masquerade as a trusted system and trusted user. 

   2. Fixing the problems

   This vulnerability can easily be closed by adding the -r option
   to the rpc.rexd entry in the /etc/inetd.conf file:

rpc  stream tcp  nowait  root  /usr/etc/rpc.rexd  100017  1 rpc.rexd -r

   Rexd should only be invoked with the "-r" option.  This
   option specifies that only hosts listed in /etc/hosts.equiv
   are permitted to use the rexd.  


I. Sendmail Vulnerabilities

   HP Security Bulletin #25 provides a list of the latest
   sendmail patches.  By installing these patches, all
   known sendmail bugs are fixed.  Even though SATAN
   tries to infer the status of sendmail by connecting
   to the SMTP port and reading the banner, this will not
   directly provide information on the patch level. 

   Consider using site hiding in your /usr/lib/sendmail.cf file
   (the DY macro) to hide system names inside your network.


J. X Server Access

   Users should not run with "xhost +", as this permits access
   to the X server from arbitrary hosts.  A better level of
   protection is provided by at least specifying hosts which
   are permitted access by using "xhost +<hostname>" where
   <hostname> is the name of a host. 

   Client-side authentication is also available in the 
   xauth authority file utility, which uses the MIT-MAGIC-
   COOKIE-1 protocol.    


K. NTP vulnerabilities and HP-DCE/9000

   1. The Problem

   When Satan is run to analyze the vulnerabilities of an HP-UX system
   whose time is synchronized by NTP, the time of the system can be set
   forward by several years.  This vulnerability can affect DCE cells that
   use NTP as a time source, either with the dts_ntp_provider or with the
   dts_null_provider running on an NTP client.  In this event, the Cell
   Directory Service (CDS) can become locked at this future date,
   rendering the DCE cell inoperable.

   2. Fixing the Problem

   Hewlett-Packard recommends you configure your HP-DCE/9000 systems to
   use either the dts_spectracom_provider or to use the dts_null_provider
   without NTP. Further information on how to use NTP in conjunction
   with DTS is available from your HP support contact.


........................................................................

II. Additional Advice on Network Security 

SATAN is quite extensible, so it is probable that these
issues will become important during the impending 
growth of the program.


A. Fingerd

   Running fingerd can allow outsiders to find login names 
   (finger @system.domain), helping them to build up information on 
   users.  

   1. The problem

   The default setting for fingerd in the /etc/inetd.conf file is
   as follows:

#finger       stream tcp nowait bin /etc/fingerd  fingerd

   If you uncomment this line to enable fingerd, an intruder can
   use this program to discover user information on your system.

   2. Fixing the problem

   This vulnerability can easily be closed by adding access control
   to /usr/adm/inetd.sec for this service, such as the following line:

finger  allow   10.3-5 192.34.56.5 ahost anetwork


B. Inetd and /usr/adm/inetd.sec

   The two important functions of a TCP wrapper program are 
   connection logging and access control.

   1. /usr/adm/inetd.sec

   Use inetd.sec to list which outside hosts and networks are 
   permitted to use services.  

   When inetd accepts a connection from a remote system, it checks the
   address of the host requesting the service against the list of hosts
   to be allowed or denied access to the specific service (see
   inetd(1M)).  The file inetd.sec allows the system administrator to
   control which hosts (or networks in general) are allowed to use the
   system remotely.  This file constitutes an extra layer of security in
   addition to the normal checks done by the services.  It precedes the
   security of the servers; that is, a server is not started by the
   Internet daemon unless the host requesting the service is a valid host
   according to inetd.sec.

   2. Inetd logging

   Be sure to start inetd with logging turned on (inetd -l) by
   modifying the /etc/netlinkrc line for inetd from:

[ -x /etc/inetd ]  &&  /etc/inetd  &&  /bin/echo "inetd  \c"

   to be:

[ -x /etc/inetd ]  &&  /etc/inetd -l &&  /bin/echo "inetd  \c"


C. Passwords

   If you ftp or telnet or rlogin across an insecure network,
   your password has traveled cleartext across networks which 
   might be traced by sniffers.  Change your password as soon as 
   possible.


D. Message Off 

   Execute 'mesg n' in each user's shell rc script (.kshrc,
   .cshrc, or .shrc, etc) to turn off each shell from being 
   world writable.


E. Denial of Service Attacks

   Denial of service attacks are always possible: the best way 
   to deal with this is to react to intrusions by adding intruder 
   source hosts/networks into the DENY listings in the inetd.sec.  
   There is no proactive way to avoid this without disabling
   networking altogether.


F. IP Spoofing

   Many of the above attacks can be combined with IP spoofing 
   to allow false IP authentication to occur.  Configure firewall
   routers to prevent externally initiated connections, as
   described in the recent CERT bulletin (CA-95:01).


G. RIP Updates

   Gated can be configured to only listen to routing updates
   from trusted gateways on all versions of HP-UX.  By default,
   gated would listen to routing updates from any source; this
   offers the potential for abuse.

   1. HP-UX 8.x:  Gated 1.9 
      Gated.conf can be modified to permit only certain 
      sources of routing information:

      trustedripgateways gateway [ gateway ] ...
      trustedhellogateways gateway [ gateway ] ...

      When these clauses are specified, gated will only listen to 
      RIP or HELLO information respectively from these RIP or 
      HELLO gateways.

   2. HP-UX 9.x:  Gated 2.1

      Gated.conf can also be modified to permit certain sources of 
      routing information.  For distance vector IGPs (RIP and HELLO) 
      and redirects (ICMP), the trustedgateways clause supplies a list 
      of gateways providing valid routing information; routing packets 
      from others are ignored.  This defaults to all gateways on the 
      attached networks.

   See the man page on your system for more details.


H. Controlling Root Access

   The file /etc/securetty can be used to control who can 
   login to a system as root.  By creating a file of this name
   containing the text "console", users of the system can only
   login as root by being at the console of the machine.
   See the man page for login(1) for more details.


I. DNS Searchlist / RFC 1535

   By default, a hostname lookup using the DNS resolver will
   proceed by appending the current domain to the hostname,
   attempting a lookup, and on failure, remove the leftmost
   part of the current domain, and retry.  RFC 1535 mentions 
   that there are possible attacks on this approach.  All
   current versions of HP-UX use this behavior as default.

   This behavior can be modified by using a "search" keyword
   in the /etc/resolv.conf file to specify the exact domain 
   search procedure.  (such as "search cup.hp.com hp.com")


J. Vulnerability in rusersd configuration

   1. The problem

   The default setting for rusersd in the /etc/inetd.conf file is
   as follows:

#rpc dgram udp wait root /usr/etc/rpc.rusersd 100002 1-2 rpc.rusersd

   If you uncomment this line to enable rusersd, an intruder can
   use this program to discover user account names on your system.
   Although this information is of marginal significance, it does
   add to the intruder's list of information about your system.

   2. Fixing the problem

   This vulnerability can easily be closed by adding access control
   to inetd.sec for this service, such as the following line:

ruserd   allow   10.3-5 192.34.56.5 ahost anetwork

   Then modify the inetd.conf line to add the "-e" option.  This
   option causes the rpc.rusersd program to exit after serving
   each RPC request.

rpc dgram udp wait root /usr/etc/rpc.rusersd 100002 1-2 rpc.rusersd -e


K. Bootpd

   1. The problem

   A bootp request from a client is sent to an inetd server which 
   returns information on a boot file.  Although this information is
   of marginal significance, it does add to the intruder's list of
   information about your system.  

   2. Fixing the problem
  
   The exposure to this vulnerability can be minimized by only starting
   bootpd from inetd (and NOT as a standalone program from /etc/netbsdsrc
   with the "-s" option) and using /usr/adm/inetd.sec to control access
   to this service.  Adding a line such as: 

bootps   allow   10.3-5 192.34.56.5 ahost anetwork

   to /usr/adm/inetd.sec will only allow the specified hosts and networks
   to make bootp requests.

   Then modify the inetd.conf line to add a small timeout, say 
   one minute.  This means that after a client has made a bootp
   request, the bootpd will exit after one minute.  Modify the 
   /etc/inetd.conf line to add the -t<timeout in minutes> option:

bootps       dgram  udp wait   root /etc/bootpd   bootpd -t1





........................................................................    

III.  HP-UX Patch Information

   Hewlett-Packard recommends that all customers concerned with the
   security of their HP-UX systems apply the appropriate patches or 
   perform the actions described above as soon as possible.

   Since the first HP Security Bulletin in November, 1993, Hewlett-
   Packard has issued 25 HP-UX security bulletins.  A patch matrix
   showing all the patches referenced in these bulletins is available
   from HPSL (see instructions in Section IV.)  In addition to 
   these patches, a number of other patches related to security were
   released before November 1993.  Customers are advised to consult
   the patch catalog and install all applicable patches (security
   and otherwise) to ensure that their systems are protected.  If 
   this is not possible, customers should consider upgrading to the
   latest current HP-UX release.  

   How to Install the Patches (for HP-UX 8.x and 9.y)

   1.  Determine which patch is appropriate for your hardware platform
       and operating system, as mentioned above.

   2.  Hewlett Packard's HP-UX patches are available via email
       and World Wide Web

       To obtain a copy of the HP SupportLine email service user's guide,
       send the following in the TEXT PORTION OF THE MESSAGE to
       support@support.mayfield.hp.com (no Subject is required):

                 send guide

       The user's guide explains the process for downloading HP-UX patches
       via email and other services available.

       World Wide Web service for downloading of patches is available 
       via our URL:
        
                 http://support.mayfield.hp.com


   3.  Apply the patch to your HP-UX system.

   4.  Examine /tmp/update.log for any relevant WARNINGs or ERRORs.  This
       can be done as follows:

       a.  At the shell prompt, type "tail -60 /tmp/update.log | more"
       b.  Page through the next three screens via the space bar, looking
           for WARNING or ERROR messages.


........................................................................

IV.  HP SupportLine and HP Security Bulletins
     
     To subscribe to automatically receive future NEW HP Security
     Bulletins from the HP SupportLine mail service via electronic
     mail, send an email message to:

        support@support.mayfield.hp.com   (no Subject is required)

     Multiple instructions are allowed in the TEXT PORTION OF THE
     MESSAGE.  Here are some basic instructions you may want to use:

     To add your name to the subscription list for new security
     bulletins, send the following in the TEXT PORTION OF THE MESSAGE:

                  subscribe security_info

     To retrieve the index of all HP Security Bulletins issued to date,
     send the following in the TEXT PORTION OF THE MESSAGE:

                  send security_info_list

     To get a patch matrix of current HP-UX and BLS security
     patches referenced by either Security Bulletin or Platform/OS,
     put the following in the text portion of your message:

                  send hp-ux_patch_matrix

     World Wide Web service for browsing of bulletins
     is available via our URL:
     
                  http://support.mayfield.hp.com

     Choose "Support news", then under Support news,
     choose "Security Bulletins"


........................................................................

V.   To report new security vulnerabilities, send email to

                  security-alert@hp.com

_______________________________________________________________________

==============================================================================
CERT-NL is the Computer Emergency Response Team for SURFnet customers. SURFnet
is the Dutch network for educational, research and related institutes. CERT-NL
is a member of the Forum of Incident Response and Security Teams (FIRST).

All CERT-NL material is available under:
  http://cert.surfnet.nl/

In case of computer or network security problems please contact your local
CERT/security-team or CERT-NL  (if your institute is NOT a SURFnet customer
please address the appropriate (local) CERT/security-team).

CERT-NL is one/two hour(s) ahead of UTC (GMT) in winter/summer,
i.e. UTC+0100 in winter and UTC+0200 in summer (DST).

   Email:     cert-nl@surfnet.nl     ATTENDED REGULARLY ALL DAYS
   Phone:     +31 302 305 305        BUSINESS HOURS ONLY
   Fax:       +31 302 305 329        BUSINESS HOURS ONLY
   Snailmail: SURFnet bv
              Attn. CERT-NL
              P.O. Box 19035
              NL - 3501 DA  UTRECHT
              The Netherlands

NOODGEVALLEN:    06 22 92 35 64      ALTIJD BEREIKBAAR
EMERGENCIES : +31 6 22 92 35 64      ATTENDED AT ALL TIMES
CERT-NL'S EMERGENCY PHONENUMBER IS ONLY TO BE USED IN CASE OF EMERGENCIES:
THE SURFNET HELPDESK OPERATING THE EMERGENCY NUMBER HAS A *FIXED*
PROCEDURE FOR DEALING WITH YOUR ALERT AND WILL IN REGULAR CASES RELAY IT
TO CERT-NL IN AN APPROPRIATE MANNER. CERT-NL WILL THEN CONTACT YOU.
===============================================================================

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1i

iQA/AwUBOL6IEzSYjBqwfc9jEQLWsACgoiJs4D0YQfNuxO4vP6V/hJO90V4AoP0Q
v/4BQT6Q0rsF5gfIJ80VWpF7
=kCnZ
-----END PGP SIGNATURE-----