I'm not aware of anything supported under OpenBSD,but this article could be a good start towards such a project:
http://www.linuxjournal.com/article/7353
(Yes, I know the article is about Linux. But the $59 USB beaconthey used in the article is platform-agnostic.)
$ 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###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/.
An alternative to purchasing commercial PGP is to deploy GnuPG, the GNU-licensed freeware implementation:
"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"
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
http://www3.gartner.com/1_researchanalysis/focus/security2002.html
And I found these:
This is interesting:
Only 0.4% of a company’s revenue, on average, is dedicated to information security in the U.S. By 2011, however, that figure will accelerate tenfold to 4% of revenue for U.S. companies, according to Gartner Inc.’s total cost of ownership model for information security.
Workers unfamiliar with computers or who blithely open files attached to e-mail could kick off virus outbreaks or inadvertently aid hackers trying to get access to an organisations internal network.
Customer service staff at call centres can also cause security headaches for companies if they are not trained to spot or deal with people who call and try to extract information about passwords and customer accounts
