DN Print Magazine BSD News BSD Mall BSD Support Source Wars Join Us

Mirrors Primary (US) Issues August 2001

August 2001 Get BSD Contact Us Search BSD FAQ New to BSD? DN Print Magazine BSD News BSD Mall BSD Support Source Wars Join Us

T H I S M O N T H ' S F E A T U R E S From the Editor The Effects of Tuning a FreeBSD Box for High Open Packages Reaches Performance Milestone 2 by Gilbert Gong by Chris Coleman Each BSD project has its A stock FreeBSD installation delivers a system which is own 3rd party software designed to meet the needs of most users, and strives to packaging system. They are provide the best balance of safety, reliablity, and all based on the same code, performance in a multi-user environment. It is therefore not yet, each of them have optimized for use as a high performance dedicated network features that make one server. This article investigates the effect of tuning a better than the other. Open FreeBSD for use as a dedicated network server. Read More Packages is a volunteer project to unify that code base and incorporate the best features of each. The NetBSD rc.d system by Will Andrews Get BSD Stuff There's been a lot of hubbub the last few months about NetBSD's new rc.d system being the successor of 4.4BSD's. At the USENIX Annual Technical Conference 2001 in Boston, MA, I had the pleasure of sitting down to listen to Luke Mewburn of Wasabi Systems discuss the new rc system NetBSD introduced in their operating system in the 1.5 release earlier this year. Read More

Search Implementing Security in FreeBSD UNIX System, Part I by Matt Dillon Search

This is part I of a two-part security series on DaemonNews. Advanced Part I describes security in general terms while Part II drills down into specific strategies for securing common services. or Search all Daemon Read More News Daily Daemon News FreeBSD Security Guide, Chapter 1 by Aeon Flux Using an OpenBSD Firewall to Share a Cable This chapter talks about the lockdown procedures of a Modem freebsd machine. This article assumes the end user has a OpenPackages Milestone 2 general level of familarity with FreeBSD, and unix, in Released particular, file permissions, kernel configuration, file Adobe's 800-Pound Gorilla editing, and basic ssh usage. Read More on the Apple OS X Sidelines Apple's OS X is a work in progress Linux and BSD, Open Source Giants New iMacs with OS X.1 in September! by Dan Shearer

Anyone influencing information technology decisions BSD Support Forum should know something about the most widely-used operating systems. Two of these are Linux and BSD, Buffer overruns relatively unknown to the world of corporate computing. unnecessary ? Read More Screen Goes blank after XF86Setup Problems with cvsup -- R E G U L A R C O L U M N S Permission problem within KDE 2? i think Is XFree86 4.1.0-client port Answerman broken? by Gary Kline, Dirk Myers, and David Leonard

Welcome back! This month we scare, titilate and automate Source Wars you. Several questions to help you get comfy with the BSD Week 22 family this issue. These range from forwarding root's mail on host1, host2,...hostN to one convenient account to the worthiness of rdate, to the leading ways of making your system crack-proof. (--Okay, if not crack-proof, then crack-resistant.) Read More

Daemon's Advocate by Greg Lehey by Greg Lehey Daemon News Mall - There’s been a lot of news about BSD lately. It’s mainly Summer Specials related to FreeBSD, but just as Linux news has proved good for BSD in the past, news about FreeBSD will prove NetBSD 1.5.1 Pre-Order good for the other BSD projects. Read More $23.95 FreeBSD 4.3 NOW SHIPPING $35 3Ware Escalade RAID Controller $144 BorderWare Secure Server R1000 $2295 Daemon Certified Systems From the Daemon News $1097 Need Reseller Pricing? Go to Cylogistics!

Miscellaneous Credits The hard-working crew Tarball Download a tar.gz version of this issue

Open Packages Milestone 2

Chris Coleman,

A lot has happened since we started the Open Packages project. Initially I took quite a bit of flak over the notion until I managed to get the project organized a bit and gained support from our sponsors. I can't say I have proved all the naysayers wrong yet, but I have stuck to it. I know that most of those who had doubts about the project will be really pleased when we succeed.

Fortunately for me, there were others already planning this same project. When we reached Milestone 1, it seemed like developers finally started to take notice of the project and there was sufficient code that things could start happening.

Since that time, the number of OP committers has tripled and the code base has grown by more than that. The complexity has outgrown my meager coding abilities and the project has taken on a life of its own. I am no longer the sole driving force that I felt I was when I first embarked on this project.

Therefore I can't take credit for Milestone 2, which was released today. It is the work of a group of developers who want to see a unified packaging system for BSD and as many other platforms as possible.

The goal of Milestone 2 was to get the existing codebase to compile on the systems we want to support. Harlan Stenn and Will Andrews have taken this to mean any system they have access to. At the time of this release, OP is known to compile on:

FreeBSD: 2.x 3.x 4.x 5.x HPUX: 10.20 Irix Linux (specifically tested on: Debian 2.2 and unstable, Red Hat Linux 6.2 and 7.1, Mandrake 8.0, Suse 7.1, TurboLinux 6.0, Kondara 2000) NetBSD: 1.5 i386 Sparc OpenBSD: 2.9 Solaris: 2.8

Systems that didn't make it into this release, but on which work is in progress include AIX, Alpha/OSF1 [Editor's note: this was made to work less than an hour after the official M2 announcement], Alpha/Ultrix4.4, and HP-UX 11.00.

We have made a fair amount of progress, but we are far from finished. The first two milestones were aimed at getting what we have working. Then next milestones are going to add new functionality. Milestone 3 is going to see us incorporate all the remaining features from the existing BSD ports and package collections, as well as expand the number of systems supported. After milestone 3, the focus will turn to a rewrite of the package tools. Some developers have already started on design documents. I’d like to see the new package tools in full development long before we reach milestone 3, but that requires more developers than we currently have now. So if you are interested in new package tools, now is a good time to get started.

If you are currently a committer or maintain a port in any BSD ports collection, contact me about joining OP.

If you have questions, e-mail .

WWW: http://www.openpackages.org/ CVSWeb: http://cvsweb.openpackages.org/ AnonCVS: http://openpackages.org/html/anoncvs.php Mailing Lists: http://openpackages.org/mailman/listinfo/ IRC: irc.openprojects.net #openpackages

The Effects of Tuning a FreeBSD Box for High Performance

Gilbert Gong,

Introduction

A stock FreeBSD installation delivers a system which is designed to meet the needs of most users, and strives to provide the best balance of safety, reliability, and performance in a multi-user environment. It is therefore not optimized for use as a high performance dedicated network server. In this article, I will investigate the effect of tuning a FreeBSD for use as a dedicated network server.

System and Methodology

The test server was a Pentium III 600 MHz with 512MB of RAM, installed in a Super Micro P6SBU motherboard. The on-board Adaptec Ultra2 SCSI adapter was connected to an IBM DNES-309170W SA30 (8GB SCSI HDD), and the network card was a 3Com 3c905B-TX. All filesystems were standard UFS

A Celeron 400 with 128MB of RAM was used as a network client when needed. The test server was installed with FreeBSD 4.3-RELEASE. The client was installed with several versions of FreeBSD 1.

The two machines were connected with a Cisco Catalyst 2924-XL running at 100Mbit/Full Duplex.

I ran three different benchmarks against the test server, in both tuned and untuned state. The benchmark results are not meant as a real world performance measurement of the system, but only a means of comparing the relative performance of the tuned and untuned state. The benchmarks were http_load to measure http performance, postmark to measure file system performance, and postal to measure SMTP performance.

Tuning

Most of the following techniques are derived from the tuning(7) man page.

Recompile the kernel Perhaps the first step in tuning a FreeBSD box is to recompile the Kernel. Remove the options not needed by your system, and increase maxusers and the NMBCLUSTERS option. A copy of the kernel config file I used is here

Turn on soft updates One of the most critical steps in tuning a FreeBSD box is turning on soft updates (and here). Soft updates is a method of improving filesystem metadata update performance. The following commands were entered in single user mode:

tunefs -n enable / tunefs -n enable /usr tunefs -n enable /var tunefs -n enable /tmp

sysctl A few sysctl variables should be tuned for maximum performance. The following lines were added to /etc/sysctl.conf :

vfs.vmiodirenable=1 kern.ipc.somaxconn=4096 kern.maxfiles=65536

misc A few other tweaks included setting the "noatime" parameter on most of the filesystems, and paying attention to partition layout. http_load Results

For the http_load test, I installed apache 1.3.19 from the ports collection, making a change to set HARD_SERVER_LIMIT to 2048. The untuned configuration would not allow 2048 processes to run, so I set Apache to create 128 initial, and max 1024 processes. For the tuned configuration, I set Apache to have 2048 processes running at all times.

I ran http_load against the server with different numbers of concurrent requests, varying from 10 to 1000. I configured the server to respond to 10 different IP addresses, and strobed over those 10 different IP addresses. This is the page which http_load ran against. The results are graphed here.

The tuned configuration outperformed the untuned configuration by over an order of magnitude. The untuned configuration maxed out at around 17 fetches/sec, as a result of running out of network mbufs. The tuned configuration kept increasing in performance as the load was increased, from 333 fetches/sec to 509 fetches/sec (1800% to 2900% increase over untuned). The tuned configuration also had a lower percentage of errors, as shown here. postmark Results

The postmark benchmark was run with a variety of settings. First, it was run with some of the configurations documented on the home page. Those results are reported here, including a run on the FreeBSD MFS (Memory File System) for comparison. The system was then put through a series of postmark runs with different file sizes, with initial 1000 files and 20000 files. The improvement in performance is quite drastic in all cases, and ranges from a 40% to 860% increase in performance by this benchmark. postal Results

For the postal benchmark, the postfix mailer was installed from the Ports collection (postfix-20010228-pl01). The postal benchmark was then run for half hour periods with a range of parallel simultaneous connection settings. Around 15000 accounts were created on the test server, and postal was given the list of accounts to send mail to. The test runs were made back to back, with only a small break between them. This means that mail which was enqueued in an earlier run may have remained enqueued for a later run, slowing things down even more. Since this is only meant as a comparative test, the results are still good indications of the performance difference between the two configurations. The results of the postal benchmark are here. The improvement ranges from a 40% increase to a 650% increase.

Conclusion

In conclusion, we can see that a default FreeBSD installation, while optimized for safety and integrity, is not optimized for maximum performance as a dedicated network server. Particularly in cases of serving many simultaneous connections, reliably supporting large numbers of processes, and filesystem performance, one needs to take steps to improve the performance of the system over the default configuration. The gains that can be realized from this are great, often at least doubling the performance of the system.

Footnotes

1 A security enhancement in 4.3 Release unintentionally slows the rate at which two servers may communicate with one another. It also does not allow a way to turn that behavior off, though a patch has been released which does allow that behavior to be changed.

The NetBSD rc.d System

Will Andrews,

There's been a lot of hubbub the last few months about NetBSD's new rc.d system being the successor of 4.4BSD's. At the USENIX Annual Technical Conference 2001 in Boston, MA, I had the pleasure of sitting down to listen to Luke Mewburn of Wasabi Systems discuss the new rc system NetBSD introduced in their operating system in the 1.5 release earlier this year.

In general, the presentation gave me the feeling that NetBSD really did explore all options possible for making rc.d more flexible. They looked at the original 4.4BSD system, which was, for the most part, untouched in NetBSD, FreeBSD, and OpenBSD, in addition to Solaris 7's System V rc system. They fleshed out everything on the mailing lists.

Th design considerations for the new system aimed at overcoming three issues in the 4.4BSD rc.d scheme. First, system admins couldn't control the order in which daemons started up. Second, there was no easy way to control an individual daemon after the system was booted -- in other words, daemons either had to provide their own interface to stop, restart, or check the status of the daemon, or they didn't provide one. When they did, it sometimes took forever to figure out what the specific commands were. Third, Luke's presentation noted that the 4.4BSD system didn't really cater to third-party additions, especially for inserting them into arbitrary points in the boot sequence. In my opinion, however, it provides just fine for these third-party daemons, EXCEPT when they needed to be inserted somewhere before the end of the rc boot sequence. So again, NetBSD's new rc.d system is the logical expansion over the age-old 4.4BSD system.

After the design (which I'll explain below) was determined, NetBSD next considered the requirements of their new system. Preserving the current /etc/rc.conf was one of the requirements I had in mind, and the NetBSD developers had agreed. After all, doing otherwise would break countless systems, and there doesn't really seem to be a better way to store central configuration variables especially given that rc is a shell script system.

Another requirement of the new system was that it support dynamic dependency ordering. This is very important because it will avoid the need to edit third-party (and other) startup/shutdown scripts and the need for an arcane ordering method e.g. "S99imapd.sh". A dynamic ordering method will allow an rc scripter to worry only about the orders that are relevant for a particular service. As Luke said in his paper (referenced below), if service C depends on B which depends on A, and I have a new service D to install that must start after A and before C, then I want to specify it in these terms, without having to worry about whether it starts before B, after B, or simultaenously with B. NetBSD considered several approaches to implement a dynamic ordering method, and in the end they chose a dedicated program to handle it.

One thing that I've always found annoying about rc scripts on System V style systems is that the majority do not share any code among them. NetBSD felt this was a maintenance nightmare, and in their words, "We have a C library and common Makefile fragments, so why not common shell functions?"

NetBSD also decided that arbitrary and mandatory runlevels would not help system administrators manipulate services.

Given the design considerations, the new rc system was laid out as follows:

/etc/rc Good old rc startup driver script. /etc/rc.conf The usual central config file. /etc/rc.subr Central subroutines for rc scripts. /etc/rc.shutdown Shutdown script a la /etc/rc. /etc/defaults/rc.conf Defaults for rc.conf. /etc/rc.d/foo.sh New rc scripts go here, including the old monolithic /etc/rc.*. /etc/rc.conf.d/foo.conf Config files for the individual rc scripts. /sbin/rcorder Dedicated program to generate dynamic dependency ordering.

As usual, when init(8) brings the system up, it starts /etc/rc. But this time, instead of /etc/rc calling other /etc/rc.* scripts, rc calls rcorder on /etc/rc.d/*, and then calls each script returned by rcorder with an argument of "start". Similarly, when shutdown time comes, /etc/rc.shutdown is called by shutdown(8). Again, it runs rcorder(8) and calls the resulting scripts with an argument of "stop".

Each rc script is required to have "start" and "stop" arguments, and other optionally supported standard arguments include "restart", "status", and "rcvar". The first four should be pretty obvious in purpose and function to most of DaemonNews’s readers; the fifth, "rcvar", displays which /etc/rc.conf variables are relevant to the service, a very handy tool to help system administrators figure out what they need to configure.

All in all, the new rc system is a logical improvement in the BSD way of doing things. That is, the BSD way is to do things the best way possible, given all circumstances and design considerations. And NetBSD has done exactly that with their new rc system. I personally applaud their efforts, especially since they have proven willing to help other system vendors adopt it. One less difference for system admins to remember is one more reason to use UNIX systems!

More details are available in Luke Mewburn’s paper that he presented at the USENIX Annual Technical Conference.

Implementing Security in FreeBSD UNIX System, Part One

Matt Dillon,

This is part one of a two-part security series on DaemonNews. Part one describes security in general terms. Part two will drill down into specific strategies for securing common services.

The funny thing about security is that we actually have quite a lot of it in the UNIX paradigm. We have users, groups, chroot, secure levels, and jails. The only problem is that we don't use any of it by default. Most services are run as root - pop3, ftp, ssh, ident, sendmail, talkd, named, ntpd, and even the ones that aren't, such as apache, barely touch the first layer of security offered in FreeBSD: each runs as its own user and group but doesn't bother with anything else. Even when programs such as named have security-minded options, they tend to not use them by default.

How we managed to get ourselves into this mindset is an exercise in understanding human nature. You learn how to do something, you get used to it, and until someone bonks you over the head with a two-by-four, you don't deviate from that learning. The problem isn't 'unsafe languages', it's 'unsafe people'. After all, writing a safe C program is actually quite easy, you simply use asprintf() instead of sprintf(), and so forth. Running a service inside a chroot or a jail isn't too difficult: It would just work for most services if only the authors added the options. You can do it without building it into the program, but fewer programs are capable of operating that way. For example, in order for named to run as another user it must still first bind to a low numbered port, which it must do as root.

Many of the services we depend on are personal projects or university projects: Kerberos, popper, apache, and so forth. Even if we have learned to write safer programs, inexperienced college kids have not. So there is an issue of education here that can only be addressed by the teachers. Is sprintf() still being taught at UC Berkeley and MIT, I wonder?

And if you think the open-source world is bad, try dipping your toes into the commercial world. It's not just worse, it's much worse. Without peer review, commercial products tend to be chock full of bugs and security issues. Even some of the more enlightened companies, such as Sun, take an awful amount of time to adopt security-minded language features. It took many years for Sun to adopt the C snprintf() routine and as far as I know they still have not adopted asprintf(). And Microsoft? Forget it... their idea of security is to integrate everything under the sun into the operating system and then blame the user for not using a firewall if a machine is compromised.

The job of properly implementing security is still a major undertaking for the system administrator. Machines are only as secure as you make them, and security concerns are always competing against the human necessity for convenience. FreeBSD is considered reasonably secure out of the box (OpenBSD is considered the most secure), but even with the reputation, all FreeBSD really does is simply not turn on most services and provide minimal user/group sandboxing of the few remaining. FreeBSD does offer some security advice in comments so when people look at, say, the rc.conf configuration variables for named they will notice an example showing how to run named with more secure options. But we are still a far cry from offering true security for the services that can be run under our operating system. If you turn something like samba on in a FreeBSD box, you are as much at risk as you are running it on a Linux box or a Solaris box. In FreeBSD-land we like to think that we offer plenty of kernel features to allow system administrators to implement a considerably greater degree of security on their systems then with other operating systems, and we do. But it is still up to the administrators to use those features. Most services do not use them by default.

Part of my work is to attempt to secure more services by default. About a year ago I did a simple first-pass on /etc/inetd.conf and user/group restricted ntalk and comsat, and I added instructions in /etc/defaults/rc.conf on how to run named in a user/group sandbox (though the default is not to, something that will soon be fixed). Those of us in control of system distributions cannot get the authors of many of these services to program defensively, but we certainly can add layers of security on top of those services to minimize the damage. This is just the tip of the iceberg of what we can do.

Security is of particular concern in mixed networks where running the most secure software across all platforms can be inconvenient and where managers and users are almost universally uneducated in even the most common-sense security practices. Most internal networks in businesses are so completely insecure that a single machine compromise can make the entire network vulnerable. Even worse, as yesterday's mainframes and mini-computers become today's desktops in terms of processing power and storage, individual workstations in your network wind up being capable of running hundreds, even thousands of processes and dozens of services all simultaneously without breaking a sweat. Security is an age-old problem because a computer is essentially useless when it cannot communicate the information it holds to the outside, and the very fact that it must communicate is what makes it ever-vulnerable to attack.

As a UNIX system administrator, your job does not end at the network port. Your job is also to educate higher level managers (or dictate policy if you happen to be one) in regards to good security practices to prevent excessive convenience-seepage from making your systems vulnerable, and your job is to be skeptical of everything.

Security is much more then protecting against the stereotypical root compromise. An attacker often does not need to break root to cause serious damage or steal information. For example, an attacker able to break into a webserver can access anything the webserver can, including potentially your database of credit card numbers if you happen to be an E-commerce house, or perhaps log files containing personal information, or perhaps business secrets being stored on an internal network. The biggest disaster that can befall an ISP is not an attacker wiping a shell machine's disks (that's what backups are for!), but instead an attacker stealing data or password information (whether encrypted or not) which results in continuing damage for the long term.

What-if and The Layered Onion

The best approach to solving security related issues is to simply assume that everything in your network can be compromised. Start asking 'what-if' questions of yourself, then solve them using a generalist, layered-onion approach. The key is to not assume that you have successfully protected yourself from a compromise, even when you are fairly sure you have. Pose the question 'what-if X is compromised?' then answer it with 'I can do Y', then pose the question 'well, what-if Y is also compromised?' and answer it with 'then do Z', and repeat until your what-ifs become absurd :-). It is not possible to guarantee any solution, but this process forces you to think. It teaches you how to recognize the vulnerabilities in your system and if you can't fix them, at least you can monitor them (another huge strength of UNIX that something like MS Windows can't even come close to matching). Detection is just as important as prevention. What use are four layers of security if a hacker has free reign to eat through all of them before you manage to detect him? The layered onion not only protects your systems better, it gives you more time to deal with the intrusions (or intrusion attempts) that do occur. Here are some examples:

Despite your best efforts someone breaks into the user account your e-commerce webserver is running under. What if they want to deface the site? Well, make all the directories and static files owned and writable by some other user and only readable by the webserver.

What if they want to steal all my credit card numbers? Then encrypt the credit card numbers everywhere, including in any database backend you might have and don't give the webserver access to the decryption key. That mitigates the damage by preventing millions of credit card numbers from being compromised all at once, but might not prevent an attacker from intercepting new credit card numbers entered by users.

What-if they break root? Don't store the decryption key for the credit cards on this host at all, instead run your credit card charging code on a different machine entirely and only install the decryption key on that machine.

What if the network is being sniffed? Only allow encrypted connections between machines (e.g. ssh), even for things going across a LAN. What you end up with is a reasonably secure machine and, more importantly, if someone were able to break into it the amount of damage they could do would be limited (and here stealing a database holding thousands of credit cards is much more damaging then placing a backdoor on the machine!). This mitigation could have the effect of forcing the attacker to stay online or making easily auditable changes, making him more detectable, and could significantly reduce the amount of damage the attacker is able to affect.

Despite a magnificent effort on your part, one of your work-at-home employees with a cable modem connection is a little less diligent than usual. What if a hacker breaks into his machine and is able to steal his ssh keys to get to a company machine? Well, you can require that your ssh users password-protect their private key (e.g. when ssh-keygen asks for a password, type one in!).

What if the hacker figures out or steals the password? You can restrict ssh connections by IP or domain by using "from=" feature of the .ssh/authorized_keys file.

What if the hacker breaks in from your employee's machine directly and wants to steal other user's ssh keys and passwords? You could require that your users create ssh keys only on their workstations and never set up keys on the multi-user machines, limiting what could be stolen from the multi-user machine. FreeBSD provides some protection for the password file, but exploits exposing the encrypted password file have been found in the past and an attacker could then download the file and run a password breaker from the safety of his own machine. You could move the password file off-host through the use of kerberos or NIS+, or not have passwords at all ('*' them out), requiring ssh-key based authorization only. Despite a supreme effort on your part, what if a visiting client plugs his laptop into your LAN and is able to sniff packets? The first line of defense is to use a switch instead of a hub. The second line of defense is to use a managed switch that completely isolates each ethernet port. The third line of defense is lock-in the MAC and IP addresses for each port. Of course, using a managed switch is relatively expensive compared to other solutions.

What if the user compromises the LAN anyway? You could encrypt all host-host communications with IPSEC, and/or you could require that only ssh (or telnet/rlogin in encrypted-mode) be used for all communications, even those staying within your LAN. As an example of this, all internal communication except for NFS is done over ssh, at work and even in my home network, and the only thing I use NFS for (since I'm not IPSEC-encrypting it) is for occasional read-only mounts for various things. In other words, I'm paranoid, but I'm not *that* paranoid. As a system administrator you have to balance convenience against the security. If you can find a sure fire all-encompassing solution that's really great, but you should never trust any solution to solve all your problems.

Always go for a generalist solution if you can. For example, if you want to protect yourself from network sniffing you might be able to use IPSEC to encrypt everything across the board. If you want to prevent someone from stealing your password file then the obvious answer is to move the password file off the 'weak' machine entirely. If you want to protect your ntp daemon the 'restrict' clause in ntp.conf may not be enough (it wasn't for the most recent exploit found for ntpd!), but ipfw or ipfilter could easily be used to truly stomp down on unauthorized access. If you want to protect against suid-based exploits, consider turning suid off using a mount option (nosuid,nosgid)) rather then chmoding program binaries. Remember that even these solutions aren't guaranteed... for example, ipfilter was recently found to have a fragment bug in it that a smart attacker could use to bypass the filter entirely. This is why a layered onion works: There might be little holes in each layer, but usually the holes in several layers don't line up. An attacker who gets through one hole is likely to hit a brick wall in the next layer.

You can't win them all

Sometimes you just can't win. An excellent example of this is email. Most of the world uses POP3 to get email, even though IMAP is potentially a better protocol. Our windows users and even some of our UNIX users use POP3. POP3 is not encrypted, passwords are only optionally encrypted, so the email spurting back and forth across the network is almost always in-the-clear. While it is possible to install software to encrypt email - PGP, for example, most people don't bother because it is usually just too cumbersome. Additionally, to be effective, email often must be accessible from home. Some of your users might even access it from a public terminal, virtually guaranteeing that their popbox will be sniffed.

This is a case where you might not be able to win. You might not be able to dictate a policy that has an acceptable level of security without excessive inconvenience to the employees. If you do wind up having to provide external visibility for your POP3 server you can still use the layered-onion approach to mitigate the damage that could occur from that visibility. You can certainly run the pop3 daemon as something other than root. You could probably run the POP3 daemon in a jail or chrooted, or use ipfw or ipfilter to reduce its exposure. You could isolate the mail machine from other services to avoid cross pollution if the mail server were to become compromised. You can require that POP3 passwords be changed every so often, and that they definitely be different from the windows logon passwords those people use to access file sharing from their laptop. In other words, you can severely limit the consequences of a stolen email account but you may not be able to prevent it. Another example might be your DNS subsystem. The BIND distribution is notorious for containing holes. There are other name server packages available, such as DJBDNS, which are considerably more secure, but which also lack features which you might need. I personally still use BIND despite the fact that I know there are probably more holes yet to be found. I've given up on trying to run anything else... BIND is just too convenient, but that doesn't mean I haven't slopped on a couple of layers of security. In FreeBSD you can trivially run your named in a jail, in a chroot'ed environment, and as a different user and group (rather then as root). You can do all three together so if someone were able to crack BIND they wouldn't be able to do much beyond that.

All exposed subsystems have similar issues.

If there is one place where as a sysop you should dig your feet in and not compromise it would be with login access to your boxes. Simply put, there is no excuse to allow unencrypted telnet, rsh, or rlogin connections into your machines in this day and age. Just don't do it. This isn't to say that using something like kerberized telnet or ssh guarantees that you won't be rooted, but it does wipe out a whole slew of possible exploits and makes it far easier to detect what remains.

General Points on Securing a FreeBSD Machine

This is just a general list. In the second part of the series I will give explicit examples on the securing of various services.

Turn off all unnecessary services. Many people turn off inetd entirely these days by setting inetd_enable="NO" in their /etc/rc.conf.

Audit your security setup. For example, use sockstat to see what ports are exposed. Don't just assume that you've turned a service off. You might be surprised at what you see.

Did you know you can bind services to specific IP addresses? For example, if you are running named on a host to serve as a recursive server only for that host, you can bind it to localhost (127.0.0.1) so only the local host can talk to it. If you are running a server with several network interfaces you can bind internal services only to the internal (usually a 10. network) interface(s).

Use IPFW and/or IPFILTER. Just turning on the IPFIREWALL and IPFILTER kernel options offers some protection. For example, simply turning on IPFIREWALL will protect you from spoofed localhost packets. Learning how to create your own rules makes it even better. For example, I use IPFIREWALL (see man ipfw) to prevent anyone from outside a subnet from spoofing internal IP addresses. I do the same thing on our border routers. Learn how to use inclusive filters. Do not use an excluding filter. That is, use filters that say "allow A, B and C and trash everything else" rather then filters that say "disallow D, E, and F and allow everything else". If machines on a subnet are not supposed to have any external visibility, even to other subnets, then disallow incoming connections to those machines from outside their subnet. Don't be shy... it's much easier to make a network secure from the get-go then to make it permissive and then have to fight managers and users months later who began to 'leak' services and programs that you now want to block. FreeBSD is incredibly flexible when it comes to firewall operations.

Jails. A Jail is a FreeBSD specific feature that allows untrusted programs to run as root with only limited access to certain aspects of the system. See the jail manual page for more information. Jails can be used to bind an environment (programs and services) to a specific IP address and are especially useful in this regard when used on a machine with many virtual hosts to create separate, isolated environments. Combined with chrooting, it is actually possible to give individual users their own 'virtual machines' on which they have 'root' without actually giving them the real root. More importantly, it is possible to segregate services so an exploit of one service is not able to bleed into others. Jails become much more important as machines get more powerful and run more and more services.

Chrooting - The chroot command may be used to run a program inside a subdirectory and not give that program any access to the filesystem outside that subdirectory. Unfortunately chroot must generally be built into a program as an option (for example, named has the "-t" option to set itself up and then chroot to handle actual runtime operations). Attempting to chroot a shell can lead to a number of problems with programs which attempt to load shared libraries or access devices (such as /dev/null and /dev/zero), though it is possible to do.

Security levels - FreeBSD implements a kernel security level feature (man securelevel). This feature can be used to disable access to raw devices, disable the ability to load kernel modules, and enforce chflags permissions on files. A higher securelevel also enforces chflags permissions on files, such as enforcing append-only operations on log files and disallowing any changes whatsoever to certain files or directories, even by root. Running at a higher securelevel is extremely inconvenient and most people don't do it, but it is well worth the effort. I believe that the FreeBSD securelevel mechanism can be made more useful in time if combined with jails. Such features are under discussion.

Service isolation - for the services most exposed to the internet, such as your webserver, or for services that you do not entirely trust, the easiest first-onion-layer is to isolate that service on its own physical machine. If this is not practical (due to cost or space issues), definitely use the chroot, jail, and UNIX user and group features (run as something other then root) to mitigate any damage.

Backups - What if all my efforts weren't enough and someone breaks in and wipes all my data? Answer: Make backups and make sure you can get to them when something fails. Don't just assume that a tape backup system will be able to restore a machine -- actually do it to see whether it works and how long it takes to do. Sometimes restoration is time-critical and tapes are just too slow. Consider packing a bunch of high capacity hard drives into a backup machine and backing up your systems to that instead of to tape, but beware that you have to protect the backup machine itself from exploitation too. When you take the online-backup approach, you still need an offline backup (such as DVD or tape) just in case the online backup is compromised. Another advantage of having an online incremental backup is that it is very easy to use it to perform independent audits of changes made to your systems.

Logging - FreeBSD's default install runs a number of security-checking scripts from cron. Read the email they send root every day, week, and month. Even better, have your production machines syslog to some other machine rather then to local files in order to deny an attacker the ability to erase his tracks.

Restrict automated remote access - Many sysops manage automated operations on remote machines by writing cron jobs which rsh to said remote machines, then runs a command on the remote machine (such as when doing backups or log file processing). This is a glaring security hole. You can't use NIS+ or Kerberos because you are trying to automate the operation, but there are some things you can do. You can use ssh for such accessed based on an ssh key pair that does not have a password, and on the server side you can run a specific command rather then run the command the client sends over by using the command="..." feature in the .ssh/authorized_keys file. This combined with IP/domain restrictions allows you to construct a reasonably secure infrastructure for automated jobs.

Disallow unencrypted login services - Do not allow unencrypted logins. If using rlogind or telnetd, require kerberos authentication and encryption and disallow unencrypted links.

Suid and sgid programs are a thorn in your side, always, but it is usually a hassle to go mess around with the permissions on binaries because the next installworld will restore them. Consider mounting filesystems with the nosuid and nosgid mount options.

Monitor your system. Create a monitoring regimen and stick to it. By default FreeBSD generates daily, weekly, and monthly security reports, but they're useless if you don't read them. Syslog is a great tool but it's even more useful if you log to another host to prevent log edits. I could write a whole book on monitoring methodologies.

Detection (or: Script Kiddies are your Friends, but Blow Them Away anyway)

During my Best Internet years we had lots of hack attempts, and a few successes (many more successes with our IRIX boxes then our FreeBSD boxes later, mainly due to SGI never updating their utilities base and us having to learn the hard way). The hackers that went after BEST were typically either IRC weenies or script kiddies attracted to our good connectivity and bandwidth. IRC weenies break into accounts and run IRC BOTs. They try to break root and run IRC SERVERs if they can (as well as install suid root shells and the like). Script kiddies tended to break into machines solely for the purpose of breaking root and installing suid root shells and the like.

This is good because the kids almost never do anything destructive, their hacks are easy to detect (I mean, come on, running a program that listens on or connects to a socket is trivial to detect no matter what argv[0] says!), and there are so many of them that they tended to get into the machines before the hard core hackers could. We used them to hone our detection skills (these kids often used user accounts compromised due to the users giving away their password or logging in from public libraries and getting sniffed). But don't get friendly with them. If one happens your way, squeeze out as much information as you can and then throw him off the system.

The honed skill that I find the most valuable is the art of deception. Instead of trying to lock up things like log files, utmp, wtmp, and process accounting logs, one instead gets sneaky. Don't lock up log files with chflags or anything else, instead have syslog dup them in realtime to another machine and then diff them to see if anyone has modified the originals. Make a semi-realtime off-host backup of other system files and check for missing or inserted data. Instead of mounting / and /usr read-only, we instead synchronize them from a remote master and do whole filesystem comparisons nightly to see if anyone has made any unauthorized modifications.

The key to detection is to give the hacker plenty of rope to hang himself with. Most hackers are stupid (with a capital S), but even the smarter ones will try to 'clean up' after themselves by editing log files. The point here is to not completely limit the 'damage' a hacker can do if they do break in, just limit it enough so you don't have to spend hours restoring the machine and monitor the rest. Your first line of defense is your layered onion, but your insurance comes from timely detection and a comparative base.

More to come in part two of this series. Author maintains all copyrights on this article. Images and layout Copyright © 1998-2001 Dæmon News. All Rights Reserved. August 2001 Search Submit Article Contact Us Join Us Merchandise

FreeBSD Security How-To, Chapter One aeonflux,

Chapter One

Greetings follow FreeBSD users, lets begin.

First, start with a typical install. If you are not familiar with this process, you should be reading the handbook on installation before consulting this article.

In this chapter we'll talk about the lockdown procedures of a freebsd machine. This article assumes the end user has a general level of familarity with FreeBSD, and unix, in particular, file permissions, kernel configuration, file editing, and basic ssh usage.

In the second chapter we'll go depth with suid bits, file attributes and daemon configuration. In the 3rd chapter we'll talk about OpenSSL, IPSec and encryption in general, including GPG/PGP and TCFS.

First off install nmap. It's a very useful tool, and we'll be using it a bit later on to check on security and on packet filtering.

In order to install nmap, you can use the ports, or if you wish, simply use the packages.

# pkg_add -r nmap

Let me explain: nmap is a portscanning util. You can use it throughout this article as you progress through the various steps to check on your machines remote security. While nmap is an excellent tool, it does not give you a picture of local security. nmapping your servers every so often, even after they are locked down, is usually a good idea. If only to check if additional services have been added or to see if firewall rules have been modified.

Another tool I would strongly suggest is Nessus. Nessus is an excellent method for checking remote host security, and is in fact used by many professional auditors for that very purpose. Nessus is also in the ports collection and it can be found under "security/nessus".

Syslog Behavior

Next lets move to one of the most important areas of security: logging. While FreeBSD is one of the most secure operating systems around, it does have some drawbacks in the area of logging. By default things don't really log to very useful places.

Lets edit /etc/syslog.conf and make some changes.

I usually modify my security.* /var/log/security line to read like this.

security.*;auth.info /var/log/security

The reasoning behind this is simple, by default ssh logins to the logging facility auth. You can, if you like, make this a separate log file using the following in your syslog.conf instead of the above.

auth.info /var/log/auth

If you prefer, you can create another file. However, if you do this, make sure you update /etc/newsyslog.conf to include it, for example:

/var/log/auth 600 10 100 * Z

It's also a good idea to modify newsyslog.conf to fix some of the world readable permissions on some log files: for example maillog and messages log. I usually change these to 600, so that they are not readable by the world. I really don't need to have them world readable, so I modify the 644 value to 600 in the newsyslog.conf file.

/var/log/messages 600 5 100 * Z /var/log/maillog 600 7 * @T00 Z

Let us return briefly to syslog. I do not like how important data is written to console, since I plan on managing servers remotely, with respect to desktops I plan on using the console to edit system files. The log reporting to console I find is very distracting when modifying system files or doing any sort of programming. So here's how to prevent it. Comment out these lines.

# *.err;kern.debug;auth.notice;mail.crit /dev/console # *.err root # *.notice;news.err root # *.alert root

In the case of workstations or desktops, you might actually want to read information easily. Please note the following is probably not a good idea for servers or publically accessible machines as it could lead to a compromise of information.

*.* /dev/ttyvb

The above will cause all logged information to be dumped onto virtual terminal B, which is accessible via ALT-F12. It's very useful for debugging purposes, and it's the setting I use on my workstation/sandbox machine. If you do this, however, you may want to look at using "security/vlock" to lock your console when you are away from the keyboard.

Finally, to prevent users from reading these files, you'll want to issue the following commands. The reasoning is you dont want to give people any additional information, that they might be able to use against you.

# chmod 600 /etc/syslog.conf # chmod 600 /etc/newsyslog.conf SSH Configuration

Now, I think we have logging pretty much covered. (Make sure to test it out fully on your own machine.) We are now ready to move onto SSH itself. Since SSH will be your primary remote administrator tool and one of the few services running, you should pay special attention when locking it down. SSH itself can lead to a security breach, as some of us have seen.

The sshd control file is /etc/ssh/sshd_config. If your not planning on accessing your server or box remotely with anything using SSH protocol 1, then I would recommend disabling it completely. It's generally not considered as secure as protocol 2, and in any event, you should not be offering any services that you do not expressly need. This will also stop someone from hijacking the startup session and downgrading you to protocol 1 by modifying the packet carrying the version banner. This could, in theory, be done to force communication using the weaker ssh 1 protocol.

Uncomment the Protocol 2,1 line and change it to read

Protocol 2

Secondly, SSH takes up a lot of memory when it's being run and it's a commonly dos'ed service. Since each connection takes up a good chunk of memory, FreeBSD by default has a line called "MaxStartups". Personally I think the defaults are rather high, and unless you're running a shell box, the values can be lowered greatly.

MaxStartups 5:50:10

This seems far more reasonable unless you're going to have a lot of people administrating this system or you're offering shell services. Even then, this is a rather healthy value for most shell providers. Remember MaxStartups does not mean the total number of connections, only the total number of not-yet-authenticated ones. This means that 5 people can be in the process of logging on at any given point in time. On a sealed box, this is more then enough.

Fortunately, by default, FreeBSD's OpenSSH configuration disables both remote root logins and empty passwords. I'd also suggest you disable X11Forwarding by changing the X11Forwarding line to read:

X11Forwarding no

If you are running a server, the server should not have X installed to begin with, so there's no good reason to have X11Forwarding set to yes in a server configuration. The reasons for turning off X11Forwarding are simple; with X11Forwarding on, a compromised remote server will be able to send processes that can directly attach itself to your X11 session. That means it can log keystrokes, display nasty messages, and capture your display.

Obviously users can still set up X11 sessions if they use simple port forwarding, or worse, set up unencrypted connections. That, however, is difficult to stop. At least this setting will prevent the more clueless users from doing it. Also, this will give the more knowledgable ones the hint that you don't want X11 sessions going on between machines.

I also strongly suggest you move away from static passwords completely and use DSA or RSA keys. You can disable password authentication by doing the following. DSA keys are generally considered more secure, but either is fine in my opinion. PasswordAuthentication no

I will also be writing up a section on how to use DSA or RSA keys. However, at this moment I should point out that password authentication is usually not a very secure method regardless of the protocols, cause it can be socially engineered, guessed, stolen from another source or beaten out of an employee.

Also regarding sshd, if you're running a server that's going to have a lot of accounts on it, most or many of these accounts probably will not have shell access. I'd recommend doing the following, if nothing else.

AllowGroups shellusers or AllowGroups wheel

Or better still, if the number of people with shell access is relatively small you can do the following.

AllowUsers aeonflux

Or whatever your user name is. Allowing only that specific user, or users to access the machine via sshd is usually a very good idea, so you dont accidently end up giving people shell access to your machine, or allow them to setup port forwarding using ssh.

As I'm sure you're aware. If you dont want users to have shell access, you should specify /sbin/nologin as their shell. This can be done using chsh.

chsh -s /sbin/nologin user

Lastly, regarding sshd and security, sshd in FreeBSD is compiled with tcpwrappers support. While tcpwrappers are a poor replacement for proper packet filtering, I'm of the opinion that a layered security stance is best. Packet filtering can fail, tcpwrappers can fail, however if stacked one on top of the other, the whole is less likely to fail.

Open up /etc/hosts.allow

By default you'll need to remove the line "ALL : ALL : allow", as well as some of the other examples. I recommend starting off with a completely blank and fresh file, unless you've already modified your /etc/hosts.allow file, in which case add the following:

sshd : localhost : allow sshd : friendlycomputer : allow sshd : all : deny friendlycomputer is the IP address of the machine you wish to log in remotely from. I suggest against using hostnames in hosts.allow, since DNS can be compromised, spoofed or tampered with at another source, which ends up making your security dependent on another machines.

That ends our section on sshd. Lets move on to the client part. Open up /etc/ssh/ssh_config and change it to read as follows.

Host * ForwardAgent no ForwardX11 no Port 22 Protocol 2 Basically, make sure ForwardAgent and ForwardX11 are turned off, and make sure it's using Protocol 2. If you want to connect to Protocol 1 daemons, add them in to your ~/.ssh/ssh_config configurations seperately.

As a side note, this is the default behavior for more recent versions of OpenSSH in FreeBSD. However it is not in other operating systems, or in older versions of OpenSSH. It's best to get in the habit of explicitly declaring these things in the configuration files, in case the default behavior is changed at a later date. However, as it stands, it's not necessary to perform this step, although personally I do anyway.

If you'd like your failed ssh logins to show up in the nightly security email, as they probably should, you'll need to apply this patch to your /etc/security. By default, FreeBSD doesn't audit failed ssh logins. At the moment this patch only checks for failed password logins. I'm going to add failed dsa/rsa key login attempts and illegal users next. Hopefully the final patch will become part of the base install.

--- /etc/security Mon Jun 11 15:45:02 2001 +++ /etc/security Mon Jun 11 15:48:29 2001 @@ -44,6 +44,7 @@ sort -t. -r -n +1 -2 | xargs zcat -f [ -f $LOG/messages ] && cat $LOG/messages + [ -f $LOG/security ] && cat $LOG/security }

sflag=FALSE ignore= @@ -188,6 +189,12 @@ separator echo "${host} login failures:" n=$(catmsgs | grep -i "^$yesterday.*login failure" | tee /dev/stderr | wc -l) +[ $n -gt 0 -a $rc -lt 1 ] && rc=1 + +# Show "${host} SSH login failures:" +separator +echo "${host} login failures:" +n=$(catmsgs | grep -i "^$yesterday.*failed password" | tee /dev/stderr | wc -l) [ $n -gt 0 -a $rc -lt 1 ] && rc=1

# Show tcp_wrapper warning messages

Networking

We now need to move on down the OSI ladder a little, to networking. By default FreeBSD and most operating systems send a RST packet when they receive data close ports. SYN or no, they build a new whole packet and send it off, telling an attacker that the port is closed and they should continue scanning the next highest port. Usually we dont want to make portscanning easier, nor do we want to waste valuable CPU cycles in the effect of a DoS attack. So we're going to use a little feature in FreeBSD called blackhole. Consult the man page blackhole(4) if you want further information on how this works. If you are using restrict_rst I'd suggest switching over to blackholing as well. It's more effective, and restrict_rst will be removed by release 4.4, as it's already been removed from -stable.

To implement blackholing, do the following. Open up /etc/sysctl.conf and add the following lines. net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1

This will set the MIBs when you boot up. To activate the changes perform the following command.

# /bin/sh /etc/rc.sysctl

While this isn't a replacement for packet filtering, it is an additional layer of security. I use it in combination with ipfw to catch anything that falls through the ruleset, or to give me some protection when I've flushed all the rules from some reason. There is another added benefit; if you have to punch holes in your firewall to allow ftp-data, dcc requests or realplayer streaming, you wont be left completely unprotected since any data that slips through the ruleset will be blackholed anyway. It would, however, be nice if ipfw handled related states a little better.

Let's move on to basic services. You should have a pretty good idea of what services you must run and the ones you don't need. When in doubt, disable it, you can always re-enable it later if something/someone needs it. Security needs overrule productivity sometimes, and this is one of them.

First up, open up /etc/rc.conf

Unless you have a good reason to run portmap, such as NFS, NIS and so on, I'd recommend disabling it. People often scan entire network blocks looking for port 111 to see if there are any vulnerable rpc services they can exploit. If you need to run portmap I'd recommend dropping dstport 111 at your border router.

portmap_enable="NO"

Unless you're running a mail server, or mail gateway, I'd recommend putting sendmail into queueing only mode. If you need to run an actual smtp gateway I'd recommend installing postfix.

sendmail_flags="-q1m"

I'd also suggest you drop icmp redirect, which can be used to DoS or hijack sessions. Don't enable it unless you have a specific reason to do so. Even then, it's sometimes best to let packets travel the less optimal way if it benefits security.

icmp_drop_redirect="YES"

You can also log icmp redirect, however I'd suggest against it because many times Cisco routers will try to send icmp redirects for legit reasons and not as a hack attempt. Depending on your situation you can enable dropped redirect packets to be logged. Personally I do not, as packet filtering takes care of this anyway.

icmp_log_redirect="YES"

For those of you who are curious you can disable that behavior on Cisco routers by doing "no ip send-redirects" on the ethernet interface.

You can also have your machine drop SYNFIN packets. This does break the TCP specification and there are better ways to do this with IPFW (more on that later). However, if you want to do it, add this to your /etc/rc.conf

tcp_drop_synfin="YES" Also if you want this behavior to work you'll need to add the following to your kernel configuration.

options TCP_DROP_SYNFIN

Finally you'll want to chmod rc.sysctl, rc.conf and sysctl.conf to prevent your users from reading them.

# chmod 600 /etc/rc.sysctl # chmod 600 /etc/rc.conf # chmod 600 /etc/sysctl.conf

crontab and at

Next lets talk about crontab. I'm very careful which users you allow to use crontab, since it's a very powerful tool to give someone. Also, there have been many exploits in cron. It can be used by an end user to setup bots, waste resources or just annoy people. In the past, script kiddies have been known to exploit crontab to gain root access on machines. Many times this is possible through a badly designed cgi or server script. The users 'www', 'nobody' and 'bind' should definitely be denied from creating crontabs.

Create a file /var/cron/allow and put inside a list of the user you want to be able to use cron. For most situations, just allowing cron to use crontabs is acceptable. Depending on your individual needs, I suggest just doing the following. In most cases it's better to create an exclusive list, rather then creating a list of users you don't want to create crontabs.

# echo root > /var/cron/allow # chmod 600 /var/cron/allow

While we're at it, we may want to prevent /etc/crontab from being read globally. Usually this stays unmodified on a system, but there are a few cases when you may want to alter it. Regardless, there's no reason to allowing users to read it. So perform the following.

# chmod 600 /etc/crontab

Btw, if you dont use 'at' (which most people do not), then go ahead and disable it too. Remember the security motto "If you dont use it, lose it". Nature already figured this one out long ago, but we engineers aren't quite as smart. Comment out the /usr/libexec/atrun command in the /etc/crontab file.

# */5 * * * * root /usr/libexec/atrun

inetd and rate limiting inetd is also on by default. inetd usually controls alot of legacy and therefore insecure services such as telnet, ntalk and finger. There are more modern and superior replacements for inetd. However FreeBSD's inetd is actually one of the better ones around. Still, unless you need any of these services, I'd suggest disabling it completely. Check /etc/inetd.conf to see if any of these services are needed by you. FTP, for example, can also be run in daemon mode, and doesn't require inetd. To disable inetd, modify the following in your /etc/rc.conf

inetd_enable="NO"

If you're going to use FreeBSD's inetd, you should be aware that it has built rate limiting ability. You can control the rate at which ident requests, for example, are processed by doing the following:

auth stream tcp nowait/10/10 root internal auth -r -f -n -o UNKNOWN -t 30

The first 10 is the number of maxchild processes we're going to allow. The second value is the max connections per ip per minute. For ident a value of 10/10 is fine. Unless your box is a major SMTP gateway, there is no reason it should need to process more then 10 ident requests at one time. Even then, dropping ident requests doesn't stop the flow of mail. In fact, the only good reason to be running ident these days seems to be irc. If you don't irc, I'd recommend disabling the service entirely.

Rate limiting of this sort will also work for other services as well. Consult the inetd man page if you want to know about how this works.

Time

Make sure your system's clock is set correctly. If your time is incorrect, your log files will be basically worthless. Now your time doesn't need to be super dead on, but within a few minutes is usually sufficient.

By default, freebsd comes installed with ntpdate.

# date

Make sure you're in the right timezone.

# ntpdate ntp.nasa.gov

Your date should now be set correctly, using the nasa ntp server, which is from my understanding pretty accurate.

At a later date you can perform the command again and see how much clock drift you have. Usually a few seconds isn't important. You may also want to make it a cron job, in which case ntpdate should be called with the -s flag in other to divert the output to syslog.

It also be noted that your time doesn't need to be exactly dead on to the second. Odds are everyone else's won't be either. So in pratical terms, I'd say within 5 minutes is sufficient.

Since we're on the subject of time, dont you find those time marks in syslog to be particularly annoying? Want to remove them?

syslogd_flags="-ss -m 0"

Added to your /etc/rc.conf, oh and the double -s also has the nice effect of closing the udp port for syslog completely. Unless you're using syslog for logging over the network, I'd suggest setting this. Securelevels

We could talk about securelevels for an entire article, but let me boil it down to basic terms. Workstations should run at securelevel 0, since they'll probably want to run X11, and servers should probably run in 2 or 1. Depending on how often you can reboot the machine to single user mode to make major adjustments. It should also be noted that securelevels can be defeated rather easily by an intelligent cracker, but every additional layer of security helps.

Personally, I run servers at 2, and my laptop and workstations usually run at 0. In /etc/rc.conf modify the following

kern_securelevel_enable="YES" kern_securelevel="2"

Please consult man init(8), or man securelevel for more information about these. Understand exactly what each level means before implementing it.

You can reboot for these settings to take effect. Or you can just perform:

# sysctl -w kern.securelevel=2

Local Security

Local security is very important; unfortunately, it's something that few open source operating systems really pay proper attention to. If your machine is located at a colocation host, or worse, in a data center where MCSEs might be wondering about, it usually a good idea to give it some protection.

Now obviously, no form of local security is 100 percent effective. If someone wants to wreck your machine and has physical access to it, you're probably in big trouble (think hammer, bomb, or water). However, you can make it rather difficult for them to get at your data or take down your server. Many times, I've seen MCSE's who've hit ctrl-alt-del on a freebsd box thinking it was how the login was called.

Lets begin with /etc/ttys. Open it up in your favorite editor and find the console line:

console none unknown off secure

Change "secure" to "insecure", so the user is asked for the root password when going to single user mode. Be warned this will also make recovering lost root passwords more difficult, But it will prevent someone from gaining root access to your machine locally provided they do not have a boot disk.

This leads us to our next topic for discussion. Modify the BIOS so that the first and/or only boot device is the hard drive. That way, even if a CDROM or boot disk is stuck into the physical machine, FreeBSD will be loaded off the hard drive rather then any inserted media. It also goes without saying that you should password the BIOS so that a password is required to make changes (but not to boot up, because you want your server to be able to reboot without a person standing in front of it). Most modern BIOS types support this behavior.

Also, locking the case, or the whole rack, is a good idea too. However this level of physical security is beyond the scope of this document.

Next, we need to talk about virtual terminals and virtual terminal buffers. Personally I find this an area of great concern, as the virtual terminal buffer does not flush after you logoff. In other words, all of the activity you did locally in front of the machine can be reviewed if someone walks up to your machine and hits scroll lock.

There is however a solution to this on servers, and on workstations that primarily use X. You can disable the virtual console buffer altogether. To do this you'll have to edit your kernel configuration file.

Add the following lines to your kernel configuration.

SC_NO_HISTORY # This option disables back-scrolling in virtual terminals

While you're editing your kernel configuration, you may want to add a few other options relating to syscons. For more information see syscons(4).

SC_DISABLE_DDBKEY # This option disables the debug key. SC_DISABLE_REBOOT # This option disables the clt-alt-del key.

Finally, if you want login prompt to appear on a blank screen, add "clear" to your /etc/csh.logout, /etc/bash_logout, or other logout file, depending on your shell.

Packet Filtering

Even though we've already enabled blackholing, it should be noted that it's not a really great alternative to proper packet filtering. So lets talk about FreeBSD's packet filtering suite.

To use ipfw, you can either compile support into your kernel or just use the kernel modules. If you setup the rc scripts properly, the kernel module will be loaded for you when you boot up.

First let's create our own firewall rules. Create a file /etc/firewall.rules and list inside of it your own rule set. I'd recommend you chmod 600 the file too.

ipfw -q -f flush ipfw -q add 00100 allow ip from any to any via lo0 ipfw -q add 00220 deny log ip from me to any in ipfw -q add 00225 deny log tcp from any to any in tcpflags syn,fin

# check the traffic's state, let it in if we sent it, otherwise deny ipfw -q add 00230 check-state ipfw -q add 00235 deny tcp from any to any in established ipfw -q add 00240 allow ip from any to any out keep-state

# allow traffic controlling icmp ipfw -q add 00300 allow icmp from any to any icmptype 3 ipfw -q add 00301 allow icmp from any to any icmptype 4 ipfw -q add 00302 allow icmp from any to any icmptype 11 # allow dhcp from dhcp servers ipfw -q add 00401 allow udp from 24.128.1.35 67 to any 68 ipfw -q add 00402 allow udp from 24.128.1.34 67 to any 68

# allow ident requests ipfw -q add 00500 allow tcp from any to any 113 keep-state setup

# log anything that falls through ipfw -q add 09000 deny log ip from any to any

In this case my DHCP servers are 24.128.1.35 and 24.128.1.34 which are the New England mediaone dhcp servers. Be sure to add your own DHCP servers in, or if your using statically assigned ip addresses remove those lines completely.

Notice how I'm also blocking tcp packets that have the bits SYN and FIN set. This is because in the wild, for the most part, packets are not seen with this combination. It is however used by nmap and queso to fingerprint the os, since different OSes respond differently to this packet type. So it's best to log it and drop it.

Also notice the rule for dstport 113. Even if you're not running ident, it's best to put this rule in here so ident requests aren't logged. It's very annoying to have someone email you threats because their firewall caught an ident request from your network. Ident requests are not hack attempts. Therefore logging them is pointless, and harassing people about them is also pointless.

If your not going to run ident, it's best to change the rule to deny, and remove the keep-state flag. So dynamic rules are not created. Once again, do not bother to log traffic denied by this rule. It's normal network activity and not an attempted network penetration.

Now to activate these new firewall rules, perform the following:

# sh /etc/firewall.rules

Now check your connectivity and see if everything is working properly. You may also need to load the module ipfw.ko, if you do however, be sure to set:

# sysctl -w net.inet.ip.fw.verbose=1

This is needed if you want to see the dropped packets in your logs.

Now if you want all this to be set up when your machine boots, you'll need to edit your /etc/rc.conf and add the following.

firewall_enable="YES" firewall_logging="YES" firewall_script="/etc/firewall.rules"

Next you'll want to do something useful with the information we're logging. Open up /etc/syslog.conf again and add the following lines.

!ipfw *.* /var/log/ipfw.log

What this will do is send all the ipfw related data to it's own log file. In this case called ipfw.log. Next, of course, you'll have to tell syslogd what to do with that log file. Edit /etc/newsyslog.conf and add the following. /var/log/ipfw.log 600 3 100 * Z

This will do is tell syslog to create a new file /var/log/ipfw.log and give it 600 permissions, and rotate it 3 times after it reaches 100k in size, as well as compressing it when it after it’s been rotated for the first time.

Next time we’ll talk about how to actually read that ipfw data.

Chapter Two Topics

IPFW / NIDS Log Reading Dummynet bandwidth limiting Apache Configuration Local File Permissions, and suid bits Postfix Configuration, and protection against email viruses tmp, avoiding the race condition BIND Configuration comments, suggestions, flames? [email protected]

Linux and BSD, Open Source Giants

Dan Shearer,

Originally written for the LinuxSA Linux and FreeBSD Installfest 2000, this paper aims to be a succinct and factual introduction to and comparison of the Linux and BSD Operating Systems. Last edited 26th June 2001 Do Free Operating Systems Matter?

Anyone influencing information technology decisions should know something about the most widely-used operating systems. Two of these are Linux and BSD, relatively unknown to the world of corporate computing.

The numbers are there. According to the Internet Operating System Counter, as of April 1999 45% of the world's network connected machines run either Linux or BSD, and this figure appears to be growing. According to the American research firm IDC's June 2001 figures, Linux accounted for 27 percent of new worldwide operating-system licenses in 2000, and Microsoft's Windows captured 41 percent of new licenses. Estimates are difficult to make (see IDC's methodology) but it is possible to measure many millions of free operating systems in production, and reasonably conclude that there are millions more.

Microsoft says they matter. During April and June 2001 there has been confirmation that the near-monopoly of Microsoft systems on the desktop does not extend to the Internet or to departmental-type server systems. This confirmation has come from Microsoft, with a number of senior executives speaking and writing extensively on the topic of free software. It is reasonable to conclude that Microsoft regards free operating systems and the free software development model as a threat to the Microsoft dominance of desktop computing.

So these operating systems are significant. What exactly are they? Free, Open Source Software

The key difference between Linux and BSD, and all other major operating systems is that the programming source code is available on the Internet. Anyone may take the Linux and BSD source code and change it to suit their needs, usually submitting the changes to the original authors. The improvements are then available in subsequent versions of the operating system, and other people have the chance to review the improvements and make them even better. It is this liberty to reuse and change the source code that distinguishes the open source development model.

The source code is also available free of charge. UNIX Core Technology

Linux is a completely new implementation of the UNIX standards, started in Finland in 1992. Linux has succeeded where commercial UNIX failed for more than ten years, in bridging the gap between the technical capabilities of UNIX and the expectations of users brought up in the age of PCs. Linux has good support for multimedia hardware and can even emulate network clients from Microsoft, Novell and other companies. Linux contains some very new and forward-thinking operating systems research, and so it doesn't have the history of continuous small refinements and torture-testing of its stablemate, BSD.

BSD stands for ``Berkeley Software Distribution''. Its source code can be directly traced back to UNIX of the early 1980s. From a technical viewpoint, this makes BSD genuine UNIX rather than a clone, though BSD does not have the right to the UNIX trademark. The original implementation of the Internet protocols (TCP/IP) was developed on BSD, and the BSD networking stack, continuously worked on for twenty years, is very highly regarded for its stability. BSD is the most popular operating system for the 100 busiest websites in the world.

The kernel (or core) components of both BSD and Linux are UNIX-compatible. This means that if an application runs on commercial UNIX such as Sun Solaris or Hewlett Packard's HP-UX, then it will probably run on Linux and BSD with a simple recompile. In fact Linux has achieved such a presence that applications are often developed on in the first place. The Rest of the OS

The Linux and BSD kernels need applications to run in order to be useful. The central group of key applications for both contains many contributions from the GNU Free Software Project.

The applications that are normally supplied with these operating systems are identical between Linux and BSD. There are about ten thousand open source packages, including graphical user interfaces, web servers, mail servers, file servers and much more. A new user can simply opt to have some reasonable choices made for them by installing a pre-selected group of open source applications, in what is called a distribution of the operating system.

It is perfectly possible (and often desirable) to run fully-commercial, closed source application software on Linux and BSD. Despite some wild claims to the contrary, the license terms of the underlying operating system have nothing to do with the intellectual property rights of the applications it is used to run. Versions, Versions...

Because the full source code is available to anyone for modification there have been numerous instances of groups taking the source code and packaging it up in a way that they like better. This doesn't mean that they are necessarily incompatible (the same UNIX programs still run just as well on all Linux and BSD distributions) but they are packaged for users with different goals such as security, speed, ease of use, Asian languages and so on.

There are only three open source BSD distributions: FreeBSD, OpenBSD and NetBSD. They are all similar in terms of the user experience, and none of them have the point-and-click installation and beginner's handholding emphasis that many Linux distributions have. http://www.FreeBSD.org is the most popular site for information about the BSDs. http://www.openbsd.org aims for maximum security as the foremost criterion. BSD/OS is a well-known commercial BSD derivative sold by Wind River Systems which is very similar to FreeBSD. BSD systems tend to be exceptionally stable platforms for Internet infrastructure.

There is a large number of Linux distributions, at least twenty major ones including Debian, Mandrake, SuSE, Red Hat, Connectiva and TurboLinux. Commercial support for Linux is available from many hundreds of companies. Detractors claim that having over 200 distributions is confusion but in practice the differences are ones of preferences than fundamental changes. It is possible to download Linux for people who speak only Chinese, Spanish, French, German and dozens of other languages, for example. Or Linux to run on your Personal Digital Assistant. Or your IBM mainframe. Verifiable stories abound on the Internet about Linux servers with years of uptime.

There are some differences in the many licenses used in software that makes up a BSD or Linux distribution. However there is no credible evidence that these differences in licensing have promoted better technical solutions. Debates about licensing tend to be unhelpful, which is perhaps why Microsoft recently switched from criticism of Open Source in general to the licensing scheme for the Linux kernel in particular. Almost nobody with a computing problem to solve will notice licensing differences between BSD and Linux. And almost everybody will benefit from at least considering what these operating systems have to offer.

Even if you are a software developer, there is still unlikely to be a licensing issue. If you happen to write software that interacts with the operating system at a very deep level then you should become familiar with the various open source licensing conditions. Which is better, BSD or Linux?

Both :-) Microsoft has showed us what happens if too much reliance is placed on any one operating system. BSD and Linux complement one another. The developers of each monitor the source code of the other with a view to improving their own product. Many companies find that the mainstream support for Linux with a choice of training, distribution supply, wide range of hardware supported and other amenities make it a sure bet. The world’s number one and number two computing hardware companies, IBM and Fujitsu have made far-reaching committments to Linux. A smaller number of companies with specific needs or staff with BSD experience have used BSD to great effect, including Microsoft Hotmail and Yahoo.

The Answer Man

Gary Kline , David Leonard , Dirk Myers

Welcome back! This month we scare, titilate and automate you. Several questions to help you get comfy with the BSD family this issue. These range from forwarding root's mail on host1, host2,...hostN to one convenient account to the worthiness of rdate, to the leading ways of making your system crack-proof. (--Okay, if not crack-proof, then crack-resistant.)

Enjoy!

What are the leading ways I can take to prevent my system from being cracked? How can I increase the serial speed through-put? What's the best way to automate log-keeping in /var/log/? What's the simplest way to put a *.jpg onto my root window? How accurate is rdate? Is it "good enough"? What are the details about running smaller fonts in the console, not X, to fit more text on each vtty? How do I forward root's mail across my network to my one account on one machine?

Q1: I just went live on the web (my own DSL) and have begun running my own DNS and Mail. I'm afraid of crackers, both kiddie and serious, malicious attacks. What are the leading ways i can prevent my system from being cracked?

A/. We can think of at least six things. Others will have different rankings, of course, but the following will get you going.

1. Identify vulnerable network services.

(a) Shutdown everything non-essential that a malicious user or cracker can use to reach your system. For example, using /etc/inetd.conf, shut down every network service that you possibly can. For starters, shutdown ftp and telnet access. Use ssh and its kin. Do you need to run fingerd? If not, turn it off; if you really want to let the outside would be able to see what you (and or your users are doing), at least run fingerd in secure mode: fingerd -d

We recommend the following manual pages: finger(1), ftp(1), telnet(1), for starters.

Also, for OpenSSH, ssh(1). A flavor of ftp, sftp, will soon be more readily available. At the present, sftp is in ports. It's worth a few keystrokes to install, and the time to read its man page (b) Make sure that services you do run are using the latest version of the software. This ensures that known bugs have been fixed; unfixed bugs in server software are the chief method by which other people can 'break in' to your system.

For example, if you are serving your own DNS make sure you have a recreent version of the BIND server; i.e., one that has recent security holes fixed. Older versions of BIND are not secure; scripts run by Windows kiddies and other miscreants still cause damage to those who don't maintain the quality of their installation.

There are plenty of mailing lists that publish daily notifications of security updates for BSD and other operating systems. Find one, subscribe to it, and pay attention to the notifications.

2. Protect authentication information.

When connecting to other computers, use ssh(1), and when transferring files, use sftp(1). These programs correctly hide your password and encrypted your password on the network, whereas telnet(1) and ftp(1) do not.

If these programs are not already installed by default, you will find one or both of them in the ports or packages area. They are certainly worth taking the few keystrokes to install, and a few moments to skim through the man page.

3. Monitor your system.

Either check your system logs daily, or install automated warning software. Programs such as tripwire and cops periodically check to see if files have been changed. Like their physical counterparts they are not foolproof but can detect many (most?) efforts to manipulate your system.

With all the logging that you can enable, most of the information in the logs is banal, ordinary, and a time consuming pain to read. What's really important is to spot anything out of the ordinary. A program like swatch can help by doing much of the sifting on your behalf and only pointing out unusual events.

Beware, though. A successful hacker can manipulate stored logs, so you may wish to have particularly sensitive programs log immediately to an isolated, write-only medium such as a dot matrix printer, a dumb terminal with lots of scrollback, or your pager.

When collecting logs from multiple machines, it is essential that their clocks are synchronised. That way, you can combine logs to detect complicated or systematic attacks.

4. Watch the data that comes through your network.

Watch the data that comes through your network.

(a) Install a firewall. This is another way of ensuring that no vulnerable service programs are exposed to the outside world. Firewalls are also able to log probes for, or attempts to use buggy services that are known to be exploitable. Many people are surprised by the number of automated scans and probing that their newly installed firewalls show up. This allows you to assess risk better.

Setting up a firewall also forces you to go through the exercise of understanding exactly what types of conversations your computer is having with the outside world.

(b) Install a mail virus checker on your mail gateway.

5. Don't run untrusted programs.

Unix viruses and trojans exist, and they often exploit the gullibility and bad habits of users. Very few programs require root privileges to run. Those that do should be considered very carefully.

So, never login as root (or start a shell as root) and then use it as a general command shell. This is just plain dangerous, as many checks are disabled when you're root. Instead, use the sudo package, and get into the habit of loging in with an unprivileged account instead. Ideally, after you have set your unix machine up, make it as inconvenient as possible to be able to do things as root. This will make it hard for trojans and viruses as well.

6. Prepare for the worst.

Make backups. Place legally valid warnings in your motd and /etc/gettytab. Take out insurance (figuratively or literally).

While these activities don't technically prevent damage to your system, they are good preparation for recovering if/when you do get hacked.

For more information on security, man security(7) the FreeBSD security mailing list

Finally, security is not an on-off property nor package that you can simply buy and/or install. It is a risk management process.

Q2 How can I increased the throughput of my serial console from the default of 9600?

A. For FreeBSD, edit the /etc/make.conf line

`BOOT_COMCONSOLE_SPEED='

where is 38400, 57600, or 115200. Then recompile and install the boot blocks as:

# cd /usr/src/sys/boot/i386/boot2 # make # make install

Edit /etc/ttys for the correct speed and terminal type. For example, change :

ttyd0 "/usr/libexec/getty std.9600" vt220 on secure to

ttyd0 "/usr/libexec/getty std.115200" vt220 on secure

for each /usr/libexec/getty line that lists a standard serial bit rate.

After you have rebooted, your consoles will run at the faster rate.

Under OpenBSD, edit /etc/ttys in a manner like the above, and then edit the file /etc/boot.conf and insert the lines: set tty com0 stty com0 115200

Q3: I've recently started to log certain events happening on my ststem, but the logfile in /var/log is growing getting huge. So far I've been deleting the logfile every few days to a week. What is a better solution?

A: You need to put entries in /etc/newsyslog.conf after you've put them in /etc/syslog.conf. /etc/syslog.conf causes the logging to happen, while entries in /etc/newsyslog.conf cause them to be rotated (or not if they aren't in there).

Read the newsyslog(1) man page carefully--better to read a hardcopy. If your printer handles PostScript, and you are using FreeBSD's man:

% man -p newsyslog | lpr will print out three pages that you can quietly study in detail. (The BSD man page documentation is getting much better and reading docs off line can be a major plus).

The nutshell clues for a n entry in /etc/newsyyslog.conf are to follow the examples like these:

# logfilename [owner:group] mode count size when [ZB] [/pid_file] [sig_num]

/var/log/mylogfile jqs:jqs 600 10 500 * Z /var/log/iplog 644 14 100 * Z

The first column is the full name of your log file. If your login is jqs (for our mythic John Q. Smith), for mylogfile, your owner:group is jqs:jqs in the second (optional ) file.

The 644 beneath mode lets only root read and write, but everyone else read. the 10 under count tells newsyslog to keep 10 gzip'd copies.. mylogfile won't be rotated until the file is 100 kilobytes in size. when is not a n issue hrer. TThe Z indicates that the rotated files will be gzipped.

Let's go one step furrther and look at an example where yoou want to rotate logfiles at a specific time when rather than size. We'll use the httpd logs as examples, rotating once a month.

/var/log/http-access.log 644 12 * $MLD0 Z Since there is no owner:group, the logs default to root:wheel The moe is the same, 644, we are keeping 12 rotations, but here, rather than rely on size, we choose to rotate monthly, "M" and on the last day of each month "L", at midnight "0" of that day, "D", The string that does this, ism as shown, "$MLD0"... And as before, we choose gzip "Z" for the saved log files.

/var/log/http-error.log 644 12 * $MLD0 Z

Q3 How can I exclude backing up files with tar and backing up other files and diresctories?

I have searched for quite awhile in my attempts to exclude certain directories when creating a tar of my development tree, ~/devel/* and the tar -X (exclude_file) doesn't work! I tried this command:

$ tar -cvf development.tar /home/jqs/devel -X /home/jqs/devel/NoBackup

In the /home/jqs/devel/NoBackup file, I had entries such as:

/home/jqs/devel/junk /home/jqs/devel/Old

The files under these directories were still included in my backup.

A: The tar program ignores options that occur after the target directory on the command line. In this case, tar doesn't notice that you've used an exclude file. Instead of the command line above, use:

$ tar -cvf development.tar -X /home/jqs/NoBackup /home/jqs/devel so that the option is before the target directory.

To check your results

$ tar -cvf development.tar -X /home/jqs/NoBackup /home/jqs/devel

In the file named /home/jqs/NoBackput, list the files to be excluded:

/home/jqs/devel/junk /home/jqs/devel/Old

$ tar -tvf development.tar will show you a table of the tarball.

Another option, which may be more convienient, is to use the to use the -T syntax. With this option, tar only archives entries in the files_to_be_backed_up file.

For example: $ tar -cvf backup.tar -T ToBeBackedUpList

One common mistake is to mix flags with the - format and flags with the -- format on the same command line. A command line with mixed-format flags will fail. Chose either "-" or "--".

For example, this command line will fail:

$ tar -cvf foobar.tar /pub --exclude /pub/DoNotSaveFilelist

Q4 What's the simplest way of putting a *.gif or *.jpg on my background window? I don't want to bother with any X Window config stuff.

%xv -root -quit -rmode 5 /usr/X11R6/etc/Background

The -quit tells xv to exit after it writes to the root window (the background). The X server won't change the root window again until it's told to by a client. -rmode 5 tells xv to display the image centred on the root window against a black background.

If you check out the following URL:

http://is.rice.edu/~shel/xv-3.10a/

you'll find more command-line options for xv.

Q5 What can you tell me about the rdate utility? If I use it every day or so, will it keep my system time reasonably accurate?

A: rdate is a simple utility that just plucks time from the time server of your choice. It's small and handy, nothing to set up-- just give the command and you're done. There are many time servers to choose from, and if all you want is to set your time once a day, then you can use a single-poll utility like rdate and have a reasonably correct time.

Use -p to 'print' the time as any user, root to actually set the machine. It has a ' -a ' switch to 'gradually skew the time' to match the server without a sudden hop.

$ /usr/local/sbin/rdate -p time.u.washington.edu Mon Aug 6 09:36:02 2001

# /usr/local/sbin/rdate -s time.u.washington.edu

Use a time server close to the machine you're synchronizing, of course.

Under OpenBSD, add a line like this to /etc/rc.conf.local: rdate_flags="time.u.washington.edu" If you *really* need accuracy, precision in timekeeping, then you would need to get one of the utilites that poll multiple servers. Once you've got this set up, timekeeping really becomes an art - if you're polling multiple time servers, you've got to take into consideration the distance they are away, how long it takes the 'time' to get to you, then you've got to work some sort of average-magic over the data you get from the various time servers, and you've got your own clock-drift to think of too.

We can't tell you precisely how many the accuracy of rdate would vary from nptd or another time synchronization method. It depends on how accurate you *need* to be.

See also the manpages for ntpq, xntpd, xntpdc.

Q6 Is it possible to have smaller fonts in a shell without running X (/dev/vttyN) so that I can fit more text on the screen?

How can I use different fonts (8x8 for example) in my local consoles ? I tried vidcontrol -f 8x8, but it reports that cannot change mode. man vidcontrol is your friend.

To use smaller fonts, you will need to set font8x8="iso-8x8" font8x14="iso-8x14" font8x16="iso-thin-8x16"

/etc/rc.conf.

It's a common mistake to try

%vidcontrol -f 8x8

. However, this only tells vidcontrol the size of the font. The ``-f'' option takes 2 arguments, the size *and* the filename. For example:

# vidcontrol -f 8x8 /usr/share/syscons/fonts/8x14

To change the font names to suit your locale - they are the names of the files in /usr/share/syscons/fonts (without the ``.fnt'').

For OpenBSD (2.9 and later), the command to change the console's size is through wsconsfg(8): wsconscfg -t 80x50 0 To load the tiny bitmapped fonts found in /usr/share/misc/pcvtfonts you can also use wsfontload(8).

Q7 I administer a rapidly growing network of BSD systems. Rather than check each machine's root mail I'd like the mail proogram to autoformard mail to one place. Is there a straightforward (easy) way of doing this? I have tried:

root [email protected]

and

root@whatevermachine [email protected]

followed by "make" to rebuild the database and HUP to sendmail, but mail from each of the root accounts still isn't forwarded.

A: As root on each machine, edit the /etc/mail/aliases file and add

root: [email protected]

Then type

# newaliases

About the Authors

Gary Kline has been porting code since the late 1970's. When he isn't hacking code, he's hacking prose or pretend poetry, or listening to jazz radio and slurping down espresso.

For four years he has been writing the software equivalent of a mind-machine, dubbed Muuz, and has already released some alpha code for FreeBSD. Check the FreeBSD ports tree if you are interested. A new release in due in the first quarter of the new century...with luck!

His most recent adventures include an ISDL link to the net, including the thrills of learning about the Domain Name System and network and mail administration.

[home|mail]

David Leonard is a PhD student in the Department of Computer Science and Electrical Engineering at the University of Queensland, Brisbane, Australia.

His area of research is QoS-adaptive component software architectures, and in his spare time is a developer for the OpenBSD project. That said, David enjoys living the quiet life with his wife, Kylie and cat, Mu. He especially enjoys frequenting Moreton Bay's many fabulous places to eat. Mmmmm!

[home|mail]

Dirk Myers does things with words, perl, and Unix.

The Daemon's Advocate: BSD in the News

Greg Lehey,

There's been a lot of news about BSD lately. It's mainly related to FreeBSD, but just as Linux news has proved good for BSD in the past, news about FreeBSD will prove good for the other BSD projects.

Two months ago I talked about Microsoft's attitude to open source software. Things didn't stop there. In the meantime, Microsoft has come in contact with BSD a couple of times. Does Microsoft run BSD code?

In mid-June, Lee Gomes, a reporter at the Wall Street Journal, followed up on a suggestion that Microsoft is using BSD code in its operating system products. In one case it was certain: the ftp client (called FTP.EXE) contains the following string:

BSD users will immediately recognize this as being part of the BSD license. Unfortunately, there's nothing of this nature in the kernel sources, and Microsoft was not handing out the source code, so the conclusion was based on an analysis of the behaviour of the stack. Lee found that yes, indeed, Microsoft uses BSD in its IP stack, and published an article in the Wall Street Journal. The article was copyrighted by Wall Street Journal, of course, and it's no longer available on their web site, but it is available online at Is Microsoft secretly using open source?. The article also discovered that Microsoft is indeed still using FreeBSD at Hotmail, despite their claims that they had eliminated all traces of FreeBSD.

The contents of the article are not the most important thing: later doubts arose as to which parts of Microsoft's IP stack really contain BSD code, since they also purchased a stack from Spider Software. Spider claims that their stack is a complete rewrite of TCP/IP. The real issue is that many people heard about FreeBSD for the first time as the result of this article. It's not really clear whether Microsoft's use of the code is an endorsement of the quality or not. Does Microsoft give BSD code?

There were a number of followups to this article. One of the most interesting was from Microsoft themself: a couple of weeks later, O'Reilly Net published an article Microsoft Plans Shared Source .NET. This article starts with:

On Wednesday, Microsoft announced plans to release what amounts to a shared-source version of its .NET infrastructure for Windows and FreeBSD.

Later in the article, John Stutz of Microsoft is quoted as saying:

The licensing terms are designed so that people who want to do non-commercial ports to Linux [can do so]. That's well within the intended purpose of the license. We don't feel comfortable with Linux because of the GPL nature of the kernel ...

FreeBSD has traditionally been an operating system that encouraged unencumbered experimentation. ... And that's what we're using it for. We're using it to prove the point that you can actually implement the CLI on Unix. It's been around a long time, people use it commercially. Microsoft uses it commercially, actually. And the academic community is quite familiar with it as well.

Still later in this article, John Osborne asked: ``So you're favoring FreeBSD over Linux because of the licensing?'', and Stutz replied ``We have chosen FreeBSD because of licensing issues, yes.''

CRN also published another article on this subject, entitled Microsoft's FreeBSD Move Aimed At Next Generation Of Developers

Sounds good, doesn't it? Well, maybe, at first sight. If you look more closely, a number of things don't seem to fit:

1. Firstly, Microsoft's .NET product seems to be of very dubious technical utility. As far as we can tell, it's just a way to weaken Sun Microsystems and their Java product, and at the same time strengthen Microsoft's monopoly. That's nothing that the BSD projects want to get involved in.

2. Secondly, it's clear that this is a shot at Linux. Viewed in the context of earlier statements, it's intended to weaken Linux and the GPL. That's nothing positive for BSD.

3. Weakening Linux at the expense of BSD might sound like a good idea to some of the more rabid fringe. If you look at it more calmly, though, it's designed to split the free software movements.

The FreeBSD community saw through these tactics. Bzdik BSD wrote:

He essentially says that they have the right to take the other people's work and screw the rest of the world over and over again. e.g. when they talk about Kerberos 'hooks'.

The real advantage of this report was the publicity that it brought for FreeBSD. As Pedro Giffuni said:

What is nice here is that in an unprecedented Press Release, Microsoft is encouraging people to use FreeBSD. The could have released binaries for Linux, after all most of this is userland code, but they chose us, apparently with a very user friendly license,.

Christian "naddy" Weisgerber wrote:

This is a rather transparent attempt at "divide et impera!" over the Open Source community. John Baldwin wrote:

I'm not sure it's really cool. M$ is just using us to snub the GPL crowd. Presumably if they actually manage to use BSD to squash the GPL, they will just turn around and attack BSD next.

In any discussion, of course, people voice different opinions. In this discussion, it was interesting to note the lack of more positive reactions to this announcement; presumably Microsoft found the reaction disappointing.

The Linux community saw pretty much the same thing. To quote the CRN article,

Linus Torvalds, the inventor and guradian of the Linux kernel, claims Microsoft's FreeBSD announcement is aimed at causing friction in the open source movement and the C# effort doesn't go far enough.

"I'd guess that somebody at MS said, "Why can't we go back to the good old days when there were tens of different UNIXes, all in-fighting?'" Torvalds told CRN in an e-mail. "I think they are a bit chicken, though. If they had any [courage], they'd have put something like IE or Office on FreeBSD. C# just isn't sharp enough." BSD at Apple

Microsoft is not the only source of news about BSD. We've known for quite some time that Darwin, the kernel of Apple Computer's new Operating System, MacOS X, is based on NetBSD and FreeBSD. Members of the Darwin project have had commit access to the FreeBSD source tree for some time.

Those ties are becoming stronger. Two members of the FreeBSD core team, Jordan Hubbard and Mike Smith, have joined Apple. We can expect to see significant cooperation with Apple in the future.

As always, significant changes worry some people, who saw Jordan in particular as becoming lost to the project. There's no reason for that, of course. Jordan has had a day job before. In any case, he addressed these concerns in his announcement:

Let me assure you all that Apple does fully understand the importance of FreeBSD and they don't want me or anyone else to stop working on it. FreeBSD doesn't compete with Apple's product offerings in any way and provides an excellent source of technology for them. Darwin is substantially based on FreeBSD 3.2 and Apple certainly doesn't want the technology transfer to end there or to be strictly one-way. Part of my mandate will in fact be helping Apple to be an even better Open Source citizen, increasing collaboration and strengthening relationships with FreeBSD and other Open Source projects.

The concerns that Jordan won't be able to devote as much time to the project as before seem unfounded. The project-related work was always in addition to his previous day job.

In any case, it's too early to know how well the cooperation between Apple and FreeBSD will work out, but we're expecting great things. Author maintains all copyrights on this article. Images and layout Copyright © 1998-2001 Dæmon News. All Rights Reserved.