Bug 232595 - xinetd may sometimes be unable to restart deactivated services
xinetd may sometimes be unable to restart deactivated services
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: xinetd (Show other bugs)
4.0
All Linux
medium Severity low
: ---
: ---
Assigned To: Jan Zeleny
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-16 06:39 EDT by David Tonhofer
Modified: 2010-02-24 04:32 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-02-24 04:32:12 EST
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 David Tonhofer 2007-03-16 06:39:11 EDT
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 10:20:23 EDT
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 12:19:10 EDT
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 09:11:45 EDT
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 04:32:12 EST
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.