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/ \ CA-96.21.tcp_syn_flooding
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 http://www.iss.net/RealSecure 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.
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:
ftp://ftp.sysadmin.com/pub/admin/tracking/req
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.
% telnet
Type QUIT to close the connection. However, if you are receiving a message that looks something like this:
Trying 10.1.5.101... telnet: connect to address 10.1.5.101: 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.
* <org-unit>.companyname.fr
but we want to publish only the upper level (i.e., companyname.fr) in our mail address. In each, there will be the following domains:
. companyname.fr . orgunit1.companyname.fr . orgunit2.companyname.fr . orgunit3.companyname.fr
the orgunitx domains will manage their own sendmail environment. There will be a mail exchanger at the companyname.fr 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?
user1: user1@orgunit1.companyname.fr user2: user2@orgunit1.companyname.fr . . .
Make sure that each alias is a unique name. Alternatively, you could hide the users behind the domain companyname.fr and require people to use the full domain name, so the email address will be user1@orgunit1.companyname.fr. 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.
Can't locate sys/socket.ph in @INC (did you run h2ph?) at ftp.pl line 52.
I have installed it on old SCO and FreeBSD.
% 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 AuthorBjorn 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.
|
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?
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.