Bug 57659 - xinetd starts doing ident requests after service attack
Summary: xinetd starts doing ident requests after service attack
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xinetd
Version: 7.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jay Fenlason
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-12-18 14:28 UTC by Daniel Senie
Modified: 2014-08-31 23:24 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-04-23 13:14:13 UTC
Embargoed:


Attachments (Terms of Use)

Description Daniel Senie 2001-12-18 14:28:46 UTC
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 21:12:39 UTC
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 21:22:18 UTC
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 21:29:48 UTC
True, I was just giving a tips for an immediate workaround.

Comment 4 Daniel Senie 2001-12-18 21:39:30 UTC
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 20:41:28 UTC
Is this still the same?

Comment 6 Mark J. Cox 2003-04-23 13:14:13 UTC
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.