Bug 232595

Summary: xinetd may sometimes be unable to restart deactivated services
Product: Red Hat Enterprise Linux 4 Reporter: David Tonhofer <bughunt>
Component: xinetdAssignee: Jan Zeleny <jzeleny>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Brock Organ <borgan>
Severity: low Docs Contact:
Priority: medium    
Version: 4.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-02-24 09:32:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.