Bug 57659 - xinetd starts doing ident requests after service attack
xinetd starts doing ident requests after service attack
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: xinetd (Show other bugs)
7.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Fenlason
Brock Organ
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-12-18 09:28 EST by Daniel Senie
Modified: 2014-08-31 19:24 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-23 09:14:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Senie 2001-12-18 09:28:46 EST
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
}
Comment 1 Trond Eivind Glomsrxd 2001-12-18 16:12:39 EST
Hmm...  not having looked into it properly yet, you could disable USERID queries
by firewalling traffic to port 113 from your system.
Comment 2 Daniel Senie 2001-12-18 16:22:18 EST
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.
Comment 3 Trond Eivind Glomsrxd 2001-12-18 16:29:48 EST
True, I was just giving a tips for an immediate workaround.
Comment 4 Daniel Senie 2001-12-18 16:39:30 EST
Appreciate the concern. Had it covered, but other folks may find the extra info 
useful if they see similar symptoms.
Comment 5 Kjartan Maraas 2003-03-31 15:41:28 EST
Is this still the same?
Comment 6 Mark J. Cox (Product Security) 2003-04-23 09:14:13 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.