| jul98.tar |
Questions and Answers
Bjorn Satdeva First some loose ends from an earlier column. On the subject of sharing files between SunXX architectures, James Hutchinson writes: Only a few files need to be saved to make this move; all you really need to do is backup everything from the sun4m system, and then pick up the /kernel and /usr/platform dirs from a sun4u system. Restore first the sun4m stuff first, then apply the sun4u stuff over the top, making sure you delete the dir trees for /kernel and /usr/platform. Also it's important to note that an Ultra I and an UltraII and Ultra5/10 use different drivers to boot from - actually, different hardware. Ultra1 uses the single-ended ESP driver, Ultra II uses the FAS fast wide driver, and I forget what Ultra5/10 uses. This requires copying the required driver into the /kernel/drv dir. After finishing the above, delete the /dev and /devices dirs and then use drvconfig, devlinks, and disks (in that order) to rebuild the /dev and /devices trees. On another topic, spam email is becoming an increasing problem; and spam filters are more and more common. However, unless they are implemented with great care, they can cause trouble. Last week, one site, for whatever reason, decided that sysadmin.com was a spam site. I don't know how they came to that conclusion, because we simply do not do any kind of spam. Normally, I would not have cared much, but in this specific case, the remote site is the home of the list maintainer of several very large mailing lists running on one of our servers. When the spam filter was put in place, any mail to the list maintainer was returned to the list, which in turn decided it was suspicious mail and forwarded it to the list maintainer for inspection. In other words, a mail loop was established, resulting in queues and log files filling up beyond their capacity. Unintentionally, the remote site had effectively created a denial of service attack on the mailing lists, and the list server had to be shut down until the whole mess was straightened out. What really bothered me, though, was that the site started blocking all mail from us, without first contacting us or in any way notifying us of what they intended to do. To me, this seems like a serious procedural error. Rather than blocking mail from anybody who might send spam mail, we could make reverse lookups on all incoming mail, and refuse to receive mail from nonexistent domains. If we also put on shields that prevent remailing, then it will take care of some of the problem. It will undoubtedly be necessary to block notorious spammers too, but that, I think, should be done with great care and according to well-thought out policies.
First of all, you will need to plug all the security holes in your operating system. Depending on the vendor and type of OS, that can be a major job. Personally, I prefer to use a BSD 4.4 system for this purpose, as I have the sources, and the kernel is a lot simpler than the SVR4 counterpart. It does not matter how much work you do to secure the anonymous ftp, if the underlying OS is easy to penetrate. Setting up a secure ftp server is not too difficult. You will need to download the Firewall Toolkit from ftp.tis.com, which contains instructions for how to get to the hidden source. The documentation shows you how to configure the Firewall Tool Kit ftp proxy as a front end to your ftp daemon. This is important because the tool kit can be configured to do a chroot. This command creates a small compartment where only the software inside the compartment can be accessed. This will ensure that even if an intruder is successful in penetrating ftp, they will not be able to get to the rest of the machine. You will also need to compile and static link the ftp daemon and the ls program so it can be used without access to the dynamically loaded libraries. I know that some version of the ftp daemon is doing a chroot of their own. If your ftpd is capable of doing that, I suggest you use that facility, as well as use the ftp proxy from TIS. While the ftpsd chroot is not 100% reliable, it does add an extra layer that must be penetrated by the intruder. Once ftp is set up as I have described above, you will need to supply all the configuration files used into the chroot'ed directory. That includes a version of the passwd file (with only user ftp) and group file, as well as the resolver file (/.etc/resolv.conf).
ftp://ftp.sysadmin.com/pub/admin/usenet/comp.sources.unix/ \
If not, check your search path and aliases to see if you are getting another program called ls. If /bin/ls is really the one who creates the behavior you describe, reinstall the original from your installation media (not from a backup tape). If this does not help, you will probably need to reinstall the machine.
As for getting tar to work here, you need to do a few things on the system where you are doing the restore. First of all, make sure you are root; if not, tar will restore the files as owned by the user who does the restore. There are some very good security reasons for this behavior. Second, make sure that your umask is set to 000, so all permissions are set as they are on the tape. Finally, make sure you use the -p option to tar (if it has it); this option tells tar to preserve the files User Id, Group Id, file mode, and access/modification times. If you do the above, you should have covered all bases. However, depending on your version of tar, you might not need everything. Try to experiment with a small archive, and see what happens. If one of the machines trusts the other, then the transfer can be performed easily over the network. Below is an example of how /usr/local/bin can be transferred in this manner.
rsh machine "cd /usr/local/bin; tar -cvf - ." | tar -xvpf - Good luck. If you hang in there, you'll soon be one of the people who has the answers.
ftp://ftp.sysadmin.com/pub/admin/usenet/comp.sources.misc/ \ There are four patches for the above. The first two can be found at:
ftp://ftp.sysadmin.com/pub/admin/usenet/comp.sources.misc/ \
The third can be found at:
ftp://ftp.sysadmin.com//pub/admin/usenet/comp.sources.misc/ \ And, the fourth patch can be found at:
ftp://ftp.sysadmin.com/pub/admin/usenet/comp.sources.misc/ \
However, in situation such as this, your best chance is to show the cost benefit of the changes. That is, how much money will your organization save over a period of time, such as one or five years, if your proposed changes are put in place. It is important to understand that most MIS departments are based in the old mainframe culture, and their idea of modern computing is often based on Microsoft or Novell. They often do not understand UNIX, and are not willing to spend any time to learn about it. Microsoft's strong point is marketing, and they have managed to obtain a major market share with what, in my opinion, is inferior software and systems. Still, it may be difficult to show an MIS department that better and more reliable solutions are available. Perhaps in their experience, UNIX is unreliable, because they have tried to run UNIX systems with people who do not have the appropriate background. The exact scenario in your environment may be different, but unless you understand where the MIS people are coming from, and try to address their concerns and fears, it will be nearly impossible for you to do anything at all.
The only DNS debugging tool I know of that doesn't have this problem is "doc - Domain Obscenity Control". Of course, I am somewhat biased towards it, since I took over maintenance of this tool from Steve Hotz and Paul Mockapetris. Nevertheless, when it comes to debugging DNS structure problems, I find it to be a very valuable tool, although not a replacement for dnswalk or nslint, since the latter can both do things as a result of looking at the entire contents of the zone. However, if nslint is considering the existence of multiple IP addresses for a name to be an "error", then I think it needs a significant rewrite. In this day and age of multi-homed and virtual hosts, such silliness is less than useless because it amounts to crying wolf. There's no sense in having this default to be an error or even a warning - maybe a notice or info, but nothing more serious.
I like nslint because it is a single program, which performs the checks quickly and efficiently. More important though, is the fact that doc requires access to the root servers. I run behind a firewall that uses forwarders and proxies without any direct Internet access, which means that I cannot use doc. This does not make doc a bad tool, it just makes it inappropriate to use here. I do, however, want to address your point of the need for zone transfers. I use nslint for domains that I am responsible for, thus, I can always set it up so that is not an issue. If somebody else wants to use either tool on my nameservers, they will not be able to, because I use a split nameserver approach. No tool will therefore be able to get to the bulk of my nameserver configuration from the outside.
I will also recommend that you make /usr/local a mountable directory, which again will come in handy when you upgrade, as you can protect your local directory by simply having it unmounted during the upgrade. You will still need to have a good backup of everything on your system. The exception to the above is for pre-existing packages, which are expected to live in specific places. For example, sendmail and configuration files should go into /etc with the standard configurations files. Whatever you do, /etc will always need some special loving care when you upgrade a system. As always, it is important to think ahead, and choose solutions that will work best over time. I know that as a new system administrator that can be very difficult. But regardless of the amount of experience you have, learn from your mistakes and attempt to make it better next time around.
I recommend that you consider a backup management package such as Amanda. Amanda is not perfect, but it does a much better job than most people can do with shell or Perl scripts in a few weeks.
Older versions of sendmail have many such security flaws. A few years back, Eric Allman, the author of the original sendmail package took a renewed interest in sendmail and has made many redesigns, improvements, and security enhancements. It is now much more difficult to break into a system or get root access to the local system if a current version of sendmail is installed (currently version 8.8.8). If you need additional security, such as on a firewall or a very large mail server, I recommend that you install smap from the TIS firewall tool kit. This will implement a wrapper around sendmail, which makes it extremely difficult for an intruder to gain access through that avenue.
Also, all modern versions of UNIX have per process limits that prevent a single process from hogging all the machine resources. If you still have to troubleshoot a machine that has become unbearably slow due to high load, you can, as a superuser, increase your job priority with the nice program. By default, a job is running with a priority of 10. A higher number means lower priority. Likewise, the superuser can get higher priority by using a lower number. Therefore, a nice 0 will give you higher priority than the other running processes, and thus a bigger piece of the pie in terms of CPU time.
awk is a pattern scanning and processing language named for its three authors Aho, Weinberger, and Kernighan. Like sed, it is a very old tool and has lost much of its use for new implementation of new tools. Today, both sed and awk have been superseded by Perl, which contains nearly all of the functionality of both awk and sed, in addition to being a complete programming language. Unless you have a special situation that requires you to use or learn awk and sed, you will be much better off learning and using Perl. Besides better overall functionality, Perl allows you to write better, clearer code. It is often difficult, even for skilled awk programmers, to understand old awk and sed scripts. n
Additional Questions and Answers, moderated by Jim McKinstry of Sprint Paranet, can be found on our Web site: www.samag.com. About the Author
Bjorn Satdeva is the president of /sys/admin, inc., a consulting firm which specializes in large installation system administration. Bjorn is also co-founder and former president of Bay-LISA, a San Francisco Bay Area user's group for system administrators of large sites. Bjorn can be contacted at /sys/admin, inc., 2787 Moorpark Ave., San Jose, CA 95128; electronically at bjorn@sysadmin.com; or by phone at (408) 241-3111.
|
I'm an avid reader of your monthly column in Sys Admin. I find both the questions and answers to be both thoughtful and accurate. I also have a question. I am an administrator for several large-scale Sun Solaris servers and have been looking for a secure ftp (with both anonymous and UID login), which provides directory security and such similar to the shareware wftpd for Windows. I have seen a number of packages that accomplish this; however, I can't decide which is best for this environment. Do you have any ideas? I'd be willing to look at something shareware, but would prefer something I could buy with confidence.
When you talk about a secure ftp server, I am assuming that you want to establish the server in a manner that does not provide a way for an intruder to gain unauthorized access.