Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 232595 - xinetd may sometimes be unable to restart deactivated services
Summary: xinetd may sometimes be unable to restart deactivated services
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: xinetd
Version: 4.0
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
: ---
Assignee: Jan Zeleny
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-16 10:39 UTC by David Tonhofer
Modified: 2010-02-24 09:32 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-02-24 09:32:12 UTC


Attachments (Terms of Use)

Description David Tonhofer 2007-03-16 10:39:11 UTC
Description of problem:

We have experienced a little DOS attack against our POP3 server.
After lots of TCP connections have been spawned, xinted's DOS protection
kicks in. 

Mar 15 20:05:33 de_dusty xinetd[3266]: FAIL: pop3 service_limit from=70.90.14.XXX
Mar 15 20:05:33 de_dusty xinetd[3266]: EXIT: pop3 status=0 pid=26374
duration=13(sec)
Mar 15 20:05:33 de_dusty xinetd[3266]: Deactivating service pop3 due to
excessive incoming connections.  Restarting in 30 seconds.
Mar 15 20:05:33 de_dusty xinetd[3266]: FAIL: pop3 connections per second
from=70.90.14.XXX
Mar 15 20:05:33 de_dusty xinetd[3266]: EXIT: pop3 status=0 pid=26030
duration=30(sec)
Mar 15 20:05:33 de_dusty xinetd[3266]: EXIT: pop3 status=0 pid=26031
duration=30(sec)
Mar 15 20:05:34 de_dusty xinetd[3266]: EXIT: pop3 status=0 pid=26032
duration=30(sec)
Mar 15 20:05:34 de_dusty xinetd[3266]: EXIT: pop3 status=0 pid=26033
duration=30(sec)
Mar 15 20:05:34 de_dusty xinetd[3266]: EXIT: pop3 status=0 pid=26034
duration=30(sec)

(Note that the line "pop3 connections per second from=70.90.14.XXX" also seems
to be missing the float saying 'how many connections per second' there were)

After 30, the pop3 service sees a restart attempt, but something clearly goes
wrong after that:

Mar 15 20:06:03 de_dusty xinetd[3266]: bind failed (Address already in use
(errno = 98)). service = pop3
Mar 15 20:06:03 de_dusty xinetd[3266]: Error activating service pop3

This can only be solved by a restart of xinted.

Could it be that already spawned processes with client sockets are inhibiting
the server socket to be bound?

Version-Release number of selected component (if applicable):

xinetd-2.3.13-4.4E.1 
on
2.6.9-42.0.2.ELsmp

How reproducible:

Haven't tried yet; I will have to get some script kiddie tool to simulate this
in my spare time.

Comment 1 Jan Safranek 2007-10-29 14:20:23 UTC
Sorry for long silence from Red Hat - requests which go through
redhat.com/support have much more attention.

I am not able to reproduce the bug - my service is correctly re-enabled after 30
seconds. Which pop3 server do you use? AFAIK we provide only cyrus-imap and
dovecot, both running without xinetd. Please provide detailed information,
including your content of /etc/xinetd.d/pop3 file.

Comment 2 David Tonhofer 2007-10-29 16:19:10 UTC
Hi,

I'm using the self-compiled Eudora QPopper behind xinetd. The pop3 is
nothing to write home about:

# default: on
# description: The pop3 server (Eudora QPopper)
# Note that the qpopper runs as 'root' but is chrooted.

service pop3
{
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        group           = root
        server          = /usr/local/qpopper/sbin/popper
        disable         = no
        # A CPS of 25 seems to be too hot in rare cases
        cps             = 40 30
        only_from       = 213.0.0.0 127.0.0.0
}

This problem hasn't occurred again so far; will have to retest if I get a couple
of hours.



Comment 3 Jan Safranek 2007-10-30 13:11:45 UTC
I do not see anything harmful in your config and I am still not able to
reproduce it (although I did not check Eudora). You can try simple script which
generates some valid POP3 connections in parallel:

USR=<add real user login here>
for i in `seq 50`
do
( (echo USER $USR; sleep 10; echo QUIT) | nc localhost pop3 ) &
done

If the bug is reproduceable, please attach a strace of xinetd -d, full content
of /etc/xinetd.d/ and /etc/xinetd.conf

It could also help if you could try to reproduce the bug with newer xinetd (from
Red Hat Enterprise Linux 5 or Fedora >=6)

Thanks in advance

Comment 4 Jan Zeleny 2010-02-24 09:32:12 UTC
Because no additional information has been provided for a long time and the issue was not reproduced, I'm closing this bug.


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