New Messages

Please send letters via email to saletter@mfi.com.

I have written once before to express my disappointment in the lack of editing for the technical content of Sys Admin Magazine. I have been a loyal subscriber since issue 1, but I'm finding it harder and harder to justify the expense of subscribing. I feel I must point out, again, how lacking an article is in technical accuracy.

The article I'm referring to is Mark Nassal's "Security - A Multi-Tiered Approach, Part 2" in the March 1998 edition. Listed below are some of the more glaring inaccuracies contained in this article:

1. tracert cannot be used to capture packets; it is the Wintel equivalent to the UNIX traceroute tool. The author is possibly referring to tcpdump, a tool similar to snoop that has the same author(s) as traceroute.

2. While it is possible to telnet to the SMTP port (25), all this connection is good for is speaking SMTP; you cannot login via this port (as the author implies), even if you have a valid user name (not UID) and password. The SMTP port is a good target for attack due to bugs in and/or misconfiguration of sendmail.

3. The author claims that TFTP "poses an even greater risk, since it is UDP based and provides no security." The fact that TFTP uses UDP as its transport protocol has no effect on its security.

4. Modifying/replacing the /etc/services file cannot (in itself) allow "unauthorized services" to become available on the system. The author is probably referring to /etc/inetd.conf.

5. NFS version 3 is not limited to Solaris. Implementations of NFS v3 are available in most commercial UNIX vendors' latest releases (AIX, HP-UX, IRIX, etc.).

6. The Solaris command to make changes to /etc/dfs/dfstab take effect is not share -a; it is shareall.

1. The URL for the author's Web site is missing the last "m", it should be http://www.tiac.net/users/nassalm.

2. The dfstab example on page 28, is missing /cdrom; what reads:

share -F nfs -o ro

should read:

share -F nfs -o ro /cdrom

These technical errors provide a major disservice to your readers. I urge you to take the steps necessary to provide for better technical review of future articles. If not, I will have no choice but to terminate my subscription.

Sincerely,
Todd Campbell
Systems Administrator
Motorola SPS/Advanced Design Technology

Thanks for your comments; I appreciate your help.

When I first received Mr. Campbell's email, I told him I would print it in the "New Messages" column. Two months later he wrote back to express his understandable dismay at not seeing it. I had been saving his letter until I had enough copy to fill this space, and only now have I received any additional letters. So, once again, I'd like to invite you all to send me criticisms, compliments, ideas, jokes, or whatever. Without those types of comments, it is difficult for us to know if we're fulfilling your expectations for this magazine. Let me know what you like and don't like, and I'll consider your suggestions. My email address is: aankerholz@mfi.com. Write to me!

Thanks for your time.
Amber Ankerholz
Managing Editor

To: saletter@mfi.com
From: Bob Marks (bmarks@illgen.com)
Topic: Donkers article in May 1998

I was stopped short when you stated that all UDP packets should be blocked. There is a whole class of time-dependent data that is made available through UDP multicasting. The destinations are unknown by the broadcaster. I know that our company could not perform its work without UDP data, and your statement should be qualified to reflect this possibility.

Dear Mr. Marks,
UDP traffic is, by its very nature, a "difficult" kind of traffic from a security point of view. There is no authentication, and the only information you can use to control it is its sender and destination addresses (and related port numbers). This information is very easy to fake; someone can completely handcraft a UDP packet and send it over the network. So, letting "foreign" UDP packets loose on your network is like opening a back door.

If you really need one or more specific UDP-based services, the best thing to do is build an isolated network with machines that use this service. Make sure it is separate from your regular network. In this way, you can protect your corporate data and systems and still use the services.

Hope that helps,
Arthur Donkers

In response to Bjorn Satdeva's (June) request for updated information about GNU compilers, David C. Bishop says:

Links for GCC for Sun systems including x86 platforms can be found at:

http://smc.vnet.et/solaris_2.5.html