Description of Problem: Occasionally the (wu-)ftp server on one of our machines gets disabled by xinetd due to excessive incoming connections from one machine. It doesn't get enabled until xinetd is manually reloaded. log files: /var/log/messages Jan 26 17:27:15 loyal xinetd[16697]: Deactivating service ftp due to excessive incoming connections. Restarting in 30 seconds. Jan 26 17:27:45 loyal ftpd[9677]: FTP session closed Jan 26 17:27:45 loyal ftpd[9680]: FTP session closed Jan 26 17:27:45 loyal ftpd[9678]: FTP session closed Jan 26 17:27:45 loyal ftpd[9679]: FTP session closed Jan 26 17:27:45 loyal ftpd[9681]: FTP session closed Jan 26 17:27:45 loyal ftpd[9683]: FTP session closed Jan 26 17:27:45 loyal ftpd[9684]: FTP session closed Jan 26 17:27:45 loyal ftpd[9682]: FTP session closed Jan 26 17:27:45 loyal ftpd[9687]: FTP session closed Jan 26 17:27:45 loyal ftpd[9689]: FTP session closed Jan 26 17:27:45 loyal ftpd[9690]: FTP session closed Jan 26 17:27:45 loyal ftpd[9688]: FTP session closed Jan 26 17:27:45 loyal xinetd[9702]: Failed to contact identity server at xxx.xxx.xxx.xxx: timeout ... <manual reload> Jan 26 17:38:21 loyal xinetd[16697]: Starting reconfiguration Jan 26 17:38:21 loyal xinetd: xinetd -USR2 succeeded ... Jan 26 17:38:22 loyal xinetd[16697]: Reconfigured: new=1 old=0 dropped=0 (services) Jan 26 17:38:22 loyal xinetd[16697]: bind failed (Address already in use (errno = 98)). service = ftp Jan 26 17:38:22 loyal xinetd[16697]: Error activating service ftp (yet it still seems to work after that) and in /var/log/secure Jan 26 17:27:15 loyal xinetd[16697]: START: ftp pid=9677 from=xxx.xxx.xxx.xxx Jan 26 17:27:15 loyal xinetd[16697]: START: ftp pid=9678 from=xxx.xxx.xxx.xxx Jan 26 17:27:15 loyal xinetd[16697]: START: ftp pid=9679 from=xxx.xxx.xxx.xxx Jan 26 17:27:15 loyal xinetd[16697]: START: ftp pid=9680 from=xxx.xxx.xxx.xxx Jan 26 17:27:15 loyal xinetd[16697]: START: ftp pid=9681 from=xxx.xxx.xxx.xxx Jan 26 17:27:15 loyal xinetd[16697]: START: ftp pid=9682 from=xxx.xxx.xxx.xxx Jan 26 17:27:15 loyal xinetd[16697]: START: ftp pid=9683 from=xxx.xxx.xxx.xxx Jan 26 17:27:15 loyal xinetd[16697]: START: ftp pid=9684 from=xxx.xxx.xxx.xxx Jan 26 17:27:15 loyal xinetd[16697]: START: ftp pid=9685 from=xxx.xxx.xxx.xxx Jan 26 17:27:15 loyal xinetd[16697]: START: ftp pid=9686 from=xxx.xxx.xxx.xxx Jan 26 17:27:15 loyal xinetd[16697]: START: ftp pid=9687 from=xxx.xxx.xxx.xxx Jan 26 17:27:15 loyal xinetd[16697]: FAIL: ftp connections per second from=xxx. Jan 26 17:27:45 loyal xinetd[16697]: EXIT: ftp pid=9677 duration=30(sec) Jan 26 17:27:45 loyal xinetd[16697]: EXIT: ftp pid=9680 duration=30(sec) Jan 26 17:27:45 loyal xinetd[16697]: EXIT: ftp pid=9678 duration=30(sec) Jan 26 17:27:45 loyal xinetd[16697]: EXIT: ftp pid=9679 duration=30(sec) Jan 26 17:27:45 loyal xinetd[16697]: EXIT: ftp pid=9681 duration=30(sec) Jan 26 17:27:45 loyal xinetd[16697]: EXIT: ftp pid=9683 duration=30(sec) Jan 26 17:27:45 loyal xinetd[16697]: EXIT: ftp pid=9684 duration=30(sec) Jan 26 17:27:46 loyal xinetd[16697]: EXIT: ftp pid=9701 duration=31(sec)
1) Which xinetd? 2) Tried just increasing the number of available connections pr. time unit?
(Sorry about the late response, I can only check my mail once a week or so these days :/) xinetd is 2.3.3-1. Last time it happened I added a per_source=5 entry and it's not happened since (could be just a coincidence), but it appears to be some kind of misbehaving ftp client that keeps on banging the server as hard as it can. Still, it shouldn't be possible to cause a DoS like this, at most the server should stop accepting connections for 30s and then try again (it doesn't seem to be doing that) Number of connections/s shouldn't be it, the load on the machine is (and should be) very low, maybe 5 simultaneous connections max.
Do you have a 'cps' directive somewhere in xinetd configs (global or specific to the ftp service)? And if so, do you also run any services with using the 'redirect' facility? I think I know why this "bind failed (Address already in use (errno = 98)). service = ftp" happens.
cps = 25 30 in the global config file, not using redirect
We are seeing the same thing happening. Apparently when the script kiddies out there try to open several ftp connections to our servers, xinetd stops taking new connections: Apr 7 05:31:40 banjo xinetd[5315]: Deactivating service ftp due to excessive incoming connections. Restarting in 30 seconds. This is fine and expected, but then it never starts allowing incoming connections again, and in this case, the only way to get ftp working again is to restart xinetd. RH 7.2 kernel 2.4.9-31 xinetd-2.3.3-1 wu-ftpd-2.6.1-20 xinetd.conf: # # Simple configuration file for xinetd # # Some defaults, and include /etc/xinetd.d/ defaults { instances = 60 log_type = SYSLOG authpriv log_on_success = HOST PID log_on_failure = HOST cps = 25 30 } includedir /etc/xinetd.d - xinetd.d/wu-ftpd: # default: on # description: The wu-ftpd FTP server serves FTP connections. It uses \ # normal, unencrypted usernames and passwords for authentication. service ftp { socket_type = stream wait = no user = root server = /usr/sbin/in.ftpd server_args = -l -a log_on_success += DURATION USERID log_on_failure += USERID nice = 10 per_source = 3 } - in a 'ps axuw', xinetd appears to be called as: xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
Just looking through my old bugs. I haven't seen this happen in recent distros, so it's probably been fixed at some point (if by nothing else, vsftpd :-) )