dc0: failed to force tx and rx to idle state

Sunfire V100 running OpenBSD 3.7 Sparc64 freshly installed offvia the official CD, is reporting "dc0: failed to force tx and rx toidle state".

Is this just cosmetic, or an actual problem?

Looking at the source code for the dc drive, this seems to be related tosetting speed and duplex (I lock the interfaces to 100/full).

I have an identical machine running 3.6, does not show this message,only the machines upgraded to 3.7 give this warning.

DNS monitor

Had a little incident today, so I ended up writing this.

Uses 'nslookup' because I actually wanted some of the nslookup side-effects;for example, it's difficult to get 'host' to "show it's work" and yetalso producethe same output in the same order each time (so the 'diff' will work correctly). Crude, yet effective.

Hopefully It'll just run quietly for years, never kicking off emails from cron,but at least now I won't be blindsided when somebody decides that simplybecause you can't ping something, it's okay to delete the host from DNS ;)

$ cat  $HOME/bin/dns-validate.pl



#! /usr/bin/perl



#



# No authorship, no copyright, no support.



# KK2005



#



#



$nslookup="/usr/sbin/nslookup";







$dir=$ENV{'HOME'}."/public_html/dns/";







$oldfile=$dir."status.then";



$outfile=$dir."status.now";







@ns= (  "127.0.0.1","207.227.240.1",



      );



#



#



#



die "Missing nslookup $nslookup $!"  unless(-x $nslookup);







chdir($dir)  die $!;



rename($outfile,$oldfile);







system("co -q -l $outfile");



open(OUT,">$outfile")  die $!;







while() {



      next if(m/^#/);



      chomp;



      print OUT "#" x 64, "\n";



      print OUT "#\n# ",$_,"#\n\n";







      foreach $server (sort(@ns)) {



              print OUT "\n # Server $server\n";



              print OUT `nslookup $_ $server`;



              print OUT "\n";



              }



      print OUT "### End $_ $nameserver###\n";



      }



print OUT "\n###\n# End nslookup\n#\n";











print OUT "\n# Contents of /etc/resolv.conf\n",`cat /etc/resolv.conf`,"\n";



print OUT "###EOF###\n";







close(OUT);



chmod(0644,$outfile);







system("ci", "-u", "-q", "-m$0", $outfile);



system("diff", "-w", "-c", "-T", $oldfile, $outfile);



exit($?);











__DATA__



#



#



# Enter your hostnames here, one per line.



# Comment lines must have a '#' as the very first character



#



# Example entries below, I recommend removing these.



#



127.0.0.1



example.com



###EOF###

Strange hardware errors? Consider a PROM Firmware upgrade

Every so often we run into a machine, physically identical to other boxes successfully converted, that fails in weird ways -- network and drive controllers not found, sporadic failure to recognize drives, etc.

Sometimes the problem turns out to be an actual hardware problem,
other times the root cause is the firmware version, either OBP
(OpenBoot PROM) or (less commonly) POST. The Sparc64 project page
hints at such issues, but does not go into details.

Sun provides a "Standalone PROM Update Utility" on CDROM, as well as
documentation on upgrading firmware:
http://sunsolve.sun.com/data/802/802-3233/pdf/802-3233-25.pdf

It is technically possible to update the PROM from a netboot server.
If you don't already have a netboot server, an alternative (suggested by Mike Scher) for systems without a CDROM drive is to keep a bootable SCA drive, containing a 32-bit Solaris and the latest prom update utility in the root partition.

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.

Unpublished Solaris RPC exploit against 'rpcbind' in the wild?

There are a growing number of (unofficial, but reliable) reports
from various sources of new, unpublished exploits targeting RPC
services on Solaris, including Solaris 2.6, 8, and Solaris 9,
both Intel and Sparc.

This is unconnected with the recent publically announced SGI/IRIX
vulnerabilities, also related to 'rpcbind' (aka 'portmapper').

The most reliable reports are of penetration and defacement against
Internet servers running Solaris 8, with all current official
Sun patches applied. There is also the possibility of the upcoming
release of "blended-threat" worms, for example, a worm with a payload
containing both an (unrelated) MS-RPC exploit for Win32/Intel and a
Solaris/Sparc exploit against rpcbind.

Any Solaris system running 'rpcbind', regardless of what services,
if any, are registered with RPC, should be considered vulnerable.

There is no official patch from Sun, this vulnerability has not been
confirmed by Sun Microsystems nor by CERT. Prior vulnerabilities of
this nature have been exploited in the wild for several months before
being officially addressed by the Sun Security Coordination Team.

On many systems, it may be possible to disable the RPC service
if no NFS or other applications/protocols which rely on RPC are in use.
If it is not possible to entirely disable the RPC service, you may wish
to consider implementing one of several mechanisms to protect the RPC
services from remote access.

We are not able to provide details or recommendations for protecting
RPC at this time. There are third-party 'rpcbind' implementations
which support TCPwrappers, however we have not done any recent testing
with this class of software.

Any system exposed on the Internet with 'rpcbind' running and
TCP port 111 accessible should be considered to be compromised.

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/

SecurityFocus Article on EAS

Gotta love the FCC.

"Insecurity Plagues Emergency Alert System"
http://online.securityfocus.com/news/613

"Though it's not known to have ever been exploited,
the spoofing risk is one of the factors quietly
driving calls to reform the EAS"

Network World: "Spam filters revealing their darker side"

Last week's "Network World" has an interesting article (excerpts below) on the perils of keyword filters.

In our spam-filtering evaluation, we are taking the majority of the steps (and implementing all of the precautions) noted in the sidebar, with the exception of using IP-based "blacklists" to reject or otherwise limit incoming messages, based on the source IP address. I have tried using lists of "known spam sources" from free or commercial "RBL" services, but have not found any such blacklists that find the right balance between effectiveness and excessive false-positives.


"Spam filters revealing their darker side"
http://www.nwfusion.com/news/2002/0909spam.html

Wireless Network auditing tool

The "netstumbler" (Wireless network discovery for Orinoco) executable is attached, or can be downloaded from http://www.stumbler.net/


I have a small GPS receiver (no display, uses serial port with power from PS/2 keyboard port), if we want to do mapping around the perimeter of the main plant

A few months ago, I drove around the public roads (outside the Company property line) and found many distinct wireless networks, mostly from apartments nearby, however two appeared to be part of the main plant deployment (need to check MACs to be sure).

policy on generic accounts?

We are in the final process of reviewing an update to the policy addressing exactly these concerns -- "generic" shared "role" accounts, service accounts, and automated processes. I have authored an amendment based on feedback from the network managers, IS Audit, and our CSO.

Our manager has received the policy for review.

The long-term solution is the implementation of mechanisms (such as single-sign on, "sudo" on Unix, and group permissions) to remove the necessity to share passwords. We realize that many of these approaches are not feasible in the current budget environment, and the password policy reflects this.

Regarding "role" accounts shared by multiple users, one of the most important requirements in the updated policy is that these passwords be changed every time an employee or contractor who had access to the password leaves (including external contractors after end of contract or when they leave employment with the contract firm, whichever comes first).

Would this "termination clause" in the new policy (over and above the standard change interval) pose an issue for your applications?

Kevin