OpenBSD Sparc64 on Sunfire V120

OpenBSD works amazingly well on "our" new SunFire V100 hardware.

With my pre-existing netboot buildout, doing a network installation on the SunFire was quick and easy -- faster than the Solaris network installation, if not quite as self-completing as my "fire and forget" firewall build boot :)

There are a number of security enhancements inherent in OpenBSD by which we can justify this admittedly unusual choice of operating system for DNS and other specialized applications where security is more important than "normalization"

Kevin


(P.S. FreeBSD 5.0 for Sparc64 supports most of the same modern Solaris systems as OpenBSD (Oddly, no Ultra-2 SCSI support, but FreeBSD does work on E220/E250) and offers SMP support for systems that have multiple CPUs)

Sudo advocacy

Some additional comments on the subject of "sudo" (http://www.courtesan.com/sudo/).

Sudo (Super User Do) is a popular solution for Unix access control, permitting regular users to run certain commands as root or as a role account, without the risks of shared passwords, and without the need for users to memorize yet another password. On many of my personal Unix systems, "sudo" is the only file with "setuid root" permission!

Has there been any consideration of the option to use the advanced (http://www.courtesan.com/sudo/intro.html) features of the "sudo" package? For example, maintaining a single global "sudoers" file on a (secure) central management host, "pushing" copies of this single standard configuration file to all managed Unix servers?

Use of a single global, centrally-managed "sudoers" file offers numerous advantages:

• Simplifies changes that affect many servers, including adding and removing access to commands and user access (allowing for near instantaneous hire/fire access updates).
• Grouping of users, of hosts, and of commands allows discrete access control from a single global file.
• This type of centrally-controlled "sudo" deployment on Solaris is used at many large corporations, including Lockheed Martin.
• Without the need for users (or even most administrators) to know the root password, this password can be stored more securely, and "root" can be a restricted "role" account under Solaris 8 RBAC.
• One single file to audit for access control of root and role account commands for all hosts.
• Automatic generation and reporting of command audit trails, locally and/or to a central log host.

I am aware of a few drawbacks, including the reasons Data Security uses this approach for other configuration files, but not for "sudoers":
Compromise of any host which uses the global "sudoers" file exposes sensitive information about the purpose, users, and access controls on other hosts using the same "sudoers" configuration.
Compromise of the central management host may make it easier to compromise the client hosts.
Effective security requires recompiling "sudo" to use SecurID authentication instead of passwords.

Automatic updating of the "sudoers" file on large numbers of remote hosts can be accomplished in a number of ways. Through the use of "ssh" and "rsync", changes to the global configuration can be distributed, via either "push" or "pull" scripting, quickly and efficiently.

The state of Email encryption: GnuPG, PGP and PGP.Com

Recently, there have been some question about the status of email encryption, both within the Company, and for communication with external users. Currently, the Company has no policy or standards regarding encryption and encrypted email. We do support production processes using encrypted files. Specifically, PGP is used to exchange sensitive information with outside vendors for XXX and certain financial applications.

There are many other useful business tasks facilitated by Public-key cryptography. More information on this technology is available on our intranet server.

IT Audit and the Network and Data Security groups have been using PGP-Freeware with positive results. As explained below, use of PGP-Freeware for business communications is no longer permissible, under PGP.Com's interpretation of the license for that product.

PGP and GnuPG public key queries and key-registration using Internet keyservers will work for HTTP keyservers (after configuration of the client proxy settings, however, registration and queries will not work using LDAP protocol to servers on the Internet. Our team no longer operates an Intranet keyserver, due to a drive failure on our development machine

There are plug-ins for PGP and GnuPG for Outlook and Outlook Express, along with many other email clients. Microsoft has no plans to directly support PGP in Outlook, Exchange or Active Directory, instead, Microsoft provides integrated support for S/MIME, using the X.509 certificate format. Here is a (somewhat dated) comparison between the various protocols:

http://www.imc.org/smime-pgpmime.html

In general, S/MIME is easier to deploy in a Microsoft-centric (Exchange and AD) environment, for purely internal communications, yet PGP/MIME (and now OpenPGP) is the de-facto standard on the Internet.

The commercial PGP division was recently sold by Network Associates. There is a new "PGP.Com" site, with information on products and pricing:
http://www.pgp.com/faq.php

Will You Continue to Support Freeware Products?
Yes. PGP will continue the tradition of freeware products for non-commercial use. The next release of PGP freeware will be in November 2002 for PGP 8.0 for Windows and MacOS X. Customers using freeware products for commercial use - using PGP freeware to communicate with licensed business users - must immediately cease usage and purchase a commercial PGP license. Products can be purchased at https://store.pgp.com/.

Company employees using the "PGP Freeware" unlicensed application must immediately cease usage.

Promotional pricing for the commercial PGP product is available through October 31st. The promotional price for "Corporate Desktop" is $70, "PGP Mail" is $45. Prices are per-seat for any quantity, these prices will increase significantly on November 1st, 2002.
http://www.pgp.com/promo.php

An alternative to purchasing commercial PGP is to deploy GnuPG, the GNU-licensed freeware implementation:

• http://www.gnupg.org/
• http://www3.gdata.de/gpg/

Network Monitoring Tools

Realtime monitoring is a particularly difficult application to implement, many monitoring products themselves can have a detrimental effect on the systems being monitored. This is one reason that WAN monitoring instrumentation needs to be implemented by our team, to avoid disruption to the WAN/routers.

Our team currently uses a combination of HP Openview, VitalNet, and other software for our network "health" information and alerting. In other enterprises (Ameritech) I have previously used Concord (http://www.concord.com/) products to the same effect. All of these solutions provide useful statistics (but not mapping) and are limited their ability to detect and deal with dependencies.


There are applications which provide a map display such as Don envisions, some in real-time, these are generally among the more expensive products. I have been working on a limited open-source application (http://sourceforge.net/projects/netmap/) providing some of this functionality, and the graphing and display issues involved are just the tip of the iceberg.

There are several map-capable products that could be considered, I've heard good things about these three:

• http://www.ipswitch.com/Products/WhatsUp/monitoring.html
• http://www.lanware.net/NetworkManagment.asp
• http://www.intermapper.com/

The most recent NWFusion buyers guide for Network Monitoring I can find (http://www.nwfusion.com/bg/netmon/netmon.jsp) was published in 1999, and is sorely out of date. They still list NetMetrix and other non-existent products, and there are probably many new products in this arena which are not included. Perhaps there are other, better, resources for locating vendors?

Traffic analysis with 'cflow' (NetFlow)

We would loke to look at Cisco's 'NetFlow' for collecting 'peak load traffic statistics from Cisco equipment. With appropriate software to generate 'executive reports' the information collected by enabling flow collection on core and edge WAN/LAN could prove valuable for collecting SLAs and for demonstrating actual utilization to support our budget allocations.

Enabling Netflow requires a substantial amount of RAM, and increases CPU utilization somewhat. Collection should not generate excessive traffic (flow data is sent as UDP packets). These assumptions need to be tested, we will have a test Cisco router for the SLB testing, I'd like to enable NetFlow on that test router initially.

It'd be great if we could get an eval of a vendor's "realtime status display" software.


Cisco Docs:

• http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/netflsol/nfwhite.htm
• http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/netflsol/nfenterp.htm

Commercial Products:

• http://www.inmon.com/trafficserver.htm
• http://www.netscout.com/

Software analysis tools:

• http://www.caida.org/tools/measurement/cflowd/
• http://rr.sans.org/software/netflow.php
• ftp://ftp.net.ohio-state.edu/users/maf/cisco/
• http://net.doit.wisc.edu/~plonka/FlowScan/