Cover V06, I01


Questions and Answers

Bjorn Satdeva

One of the biggest security-related problems on the Internet today, especially for Internet Service Providers, is vandals using SYN-flooding attacks to disable Internet sites by sending a stream of forged TCP connection requests to a listening TCP port, such as the Web server, ftp server, or mail server. These forged packets contain the SYN flag, causing new connections to be created. Because the attackers use packages with a forged source address, the connection will never complete. The connection eventually times out after about 75 seconds, but these connections fill up the queue of pending connections. As a result, the bogus connections will cause "good" connection requests to be dropped, and an otherwise functional Web and ftp site will appear to be down.

Descriptions of how to launch these attacks have been published in Phrack and 2600 - magazines that are widely read by Internet hackers. Since the publication of these articles, the frequency of SYN-flooding attacks has been on the rise, and the attacks have caused severe problems for several Internet Service Providers. The SYN attack on Panix is probably the best known, but other providers have reported similar problems.

Most systems are defenseless against these attacks. CERT has provided recommendations to Internet providers showing how the problem can be minimized. See:

ftp://ftp.sysadmin/pub/admin/alert/cert/advisorie/ \

for a more detailed description of the problem and how to protect yourself from its effects.

Two vendors have provided some relief. ISS has released RealSecure. It is a real-time network monitoring, intrusion detection and response system that attempts to prevent SYN floods from happening in the first place. If it sees SYNs not followed by Acks, it will reset the connections, thereby unclogging the ports (see for details). For most systems, this is the only proactive approach you will have to the SYN attack problem, even though it is at best a hack to workaround a problem in the TCP/IP implementation. Another system vendor, Berkeley Software Design (BSDI), had a fix out for their version of the BSD 4.4 operating system shortly after this problem became apparent. BSDI has chosen to make the source code for these enhancements available via the Internet to all interested parties.

 Q We are a medium-sized site, with about 250 UNIX machines from various vendors. My staff (2 people) and I are overloaded with work, but I have not been able to convince my manager that I need more people. Do you have any suggestions?

 A The first thing you need to do is to start to think differently and to organize your small workforce in a different way. In my years as a UNIX system administration consultant, I have seen sites in your situation too many times. Evi Nemeth, author of the UNIX System Administration Handbook refers to the art of UNIX system administration as "working in the trenches." But, I think this model is wrong.

You need to change the way you think and work. It's been my experience that many UNIX admins are so busy fighting today's fires that they have no time to plan for tomorrow. And, in the absence of planning lies the seed of tomorrow's fires.

You need to reserve some time every day to do strategic work. Start with one hour every day - one hour where you think about what kind of problems you are facing, what is the root of those problems, and then work on dealing with the root of the problem. If you do anything else, it will be only cosmetic in nature. Picture each problem as a red warning light, wanting your attention. You can deal with that warning in two ways. You can correct the situation that made the light go on, or you can unscrew the bulb. Both will get rid of the red warning light, but one solution will have only a short-term effect.

To implement this plan effectively, you first need to know how your time is currently spent. To do this, both you and your team will need to record in detail how you are spending your time. Keep an eye on interruptions. Those are efficiency killers. Studies have shown that when you are working on a task and get interrupted (e.g., by a phone call), it will take 15 to 20 minutes to get back into a good work rhythm. It is easy to see that if you get interrupted several times each hour, you will not be able to accomplish a lot during the day. Many sys admins find this to be true, as they have told me that they are more effective early morning or late afternoon/evening, when there are not as many people around.

Also, keep an eye out for recurring problem (or problems categories) and tasks. Spend your strategic time where you will get the most return!

If you do not already use a job tracking system, start to do so as soon as possible. It will help you track what needs to be done, which jobs have been completed, and how soon they were completed after the request was received. If you, or one of your sys admin's discover a problem, enter a request into the job tracking system, even if you are fixing it immediately. There are several job tracking systems available at the System Administration Archive. The best one, in my opinion, is "req", but any tracking system is better than nothing at all. The URL for req is:

Now, all of this may look like it did not answer your question, but it really did. When you know where the time is spent, how many problems your staff has fixed, what the normal turnaround time is, what the most common problems are, and can list the problems you have been unable to fix, then you can present a convincing case to your management. You should then be able to approach your management with statistics like: at the start of last month, we had 3,215 outstanding user requests; during the month, we received an additional 4,317 requests; and we resolved 3,973 requests, ending the month with 3,469 requests (in other words, 344 more than at the start of the month). This is information that your manager will be able to understand. When this information is backed up with additional facts, such as the turnaround time for each request, you will be able to build a strong case for getting more people.

 Q I need help resolving this problem: I cannot receive mail on a UNIX station, but I can send mail to another station. Is this a problem of the file? If yes, which? If not, what could it be?

 A It is likely to a much simpler problem. Always look for the simple solutions first. Check whether sendmail is running as a daemon on the host that refuses to receive email. The simplest way to check this is to telnet to the SMTP port (port 25) using this command:

% telnet  25

You should see a response like:

Connected to 
Escape character is '^]'.
220 <hostname> ESMTP Sendmail 8.8.2/8.6.5 ready at .....

Type QUIT to close the connection. However, if you are receiving a message that looks something like this:

telnet: connect to address Connection refused

your sendmail daemon has either died or has never been started. Try to reboot the system to see if that will correct the problem. If not, check your rc files to see if sendmail is started correctly. You should see a line similar to:

sendmail -bd -q30m

The -bd option will cause sendmail to run in daemon mode and listen to the network for incoming email. If you are able to connect to the SMTP port without problems, check the log mail-log for problems. If the system has problems delivering mail, you should see reasonably informative messages in there. The location of the log file is dependent on the configuration of syslog and differs between variants of UNIX. Check /etc/syslog.conf to see where the logging information is sent. Also check the log file on the sending system to see if it thinks that the mail has been delivered.

 Q As a Sys Admin magazine reader, I looking for an answer to the following question: I have heard that a new DNS naming syntax rule requires that we should not use the underscore character inside names (effective at the beginning of 1997). Can you please confirm this?

 A It is correct that you must not use underscores in hosts and domain names. This is specified in RFC 952 and is nothing new.

 Q I have a question on DNS/Sendmail name resolution. Suppose we have the following domain naming hierarchy:

* <org-unit>

but we want to publish only the upper level (i.e., in our mail address. In each, there will be the following domains:


the orgunitx domains will manage their own sendmail environment. There will be a mail exchanger at the level domain.

Is it possible to implement a name (mailbox) resolution upon the receipt of a mail from Internet between the first level mail exchanger and the other mail systems (at the lower domains) before effectively sending the message, so the bandwidth will be optimized? Is it even possible to do it at the DNS level by returning the address of the right mail exchanger?

 A There is no way for the DNS to do what you want. You need to add all users who want to receive email in the alias file on your gateway with entries such as:


Make sure that each alias is a unique name. Alternatively, you could hide the users behind the domain and require people to use the full domain name, so the email address will be If you work for a large organization, this is probably the best approach, as you only need to ensure unique user names within the scope of each subdomain.

 Q I need to change a printer configuration. However, my printcap file is read only. When I try to use the command chmod -fR +w printcap, it does not change to a write-able file.

 A Make sure you have permission to change the permission of the file (i.e., you will probably need to be root). Also, try using the old syntax. Depending on the version of your UNIX system, chmod may have some protection mechanism built in to protect you from yourself. A chmod 644 printcap should do. You did not say which version of UNIX you are using, but at least one vendor (BSDI) has added a second protection mechanism, which allows the sys admin to specify that a file can only can be changed when in single user. As a last thing, try to reboot your system, and run fsck; a damaged filesystem can have the most surprising effects.

 Q I have installed ftpmail server several times and keep getting the same message:

Can't locate sys/ in @INC (did you run h2ph?) at line 52.

I have installed it on old SCO and FreeBSD.

 A You need to run h2ph. This command comes with Perl, and will make a Perl version of your C header files. It is most easily run while in /usr/include:

% cd /usr/include
% h2ph * sys/*

If you have other subdirectories than sys in your /usr/include directory (you probably do), you will need to add them to the arguments to h2ph.

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; or by phone at (408) 241-3111.