Description of Problem: My ftp service is attacked frequently. I have configured xinetd to deal with this, but there are bugs in xinetd which are causing trouble. The bug being reported here is that xinetd, after clamping off access to a service dur to excessive connections per second, starts using Ident after re-enabling the service, even though USERID is NOT in my configs. We have a requirement that Ident NOT be used, as it causes problems for some of our customers (and provides no real value in our opinion). We're finding it impossible to disable. Version-Release number of selected component (if applicable): RPM reports: xinetd-2.3.3-1 How Reproducible: only seems to occur after attacks. I have not attempted to attack my server to the point of failure. Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information: Here's my wu-ftpd config file for xinetd: # default: on # description: The wu-ftpd FTP server serves FTP connections. It uses \ # normal, unencrypted usernames and passwords for authentication. service ftp { disable = no instances = 25 socket_type = stream wait = no user = root server = /usr/sbin/in.ftpd server_args = -l -a log_on_success += DURATION nice = 10 per_souce = 3 }
Hmm... not having looked into it properly yet, you could disable USERID queries by firewalling traffic to port 113 from your system.
It is possible to work around this problem with an IPCHAINS rule on OUTBOUND traffic, which does a REJECT (so that an ICMP packet goes back to xinetd). However this becomes more of an issue to manage, since it'll affect all applications, and that's not necessarily desirable. The underlying bug here is I don't have USERID turned on for the service. Should not be necessary to fool the thing if it's works as documented.
True, I was just giving a tips for an immediate workaround.
Appreciate the concern. Had it covered, but other folks may find the extra info useful if they see similar symptoms.
Is this still the same?
Red Hat Linux 7.0 is no longer supported and xinetd has been updated in newer distributions. Please reopen this bug if you see the problem still occur in Red Hat Linux 7.1 or later.