Bug 104200 - rhnsd or up2date process floods network
rhnsd or up2date process floods network
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Fanny Augustin
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-11 03:06 EDT by Ian Hoyle
Modified: 2007-04-18 12:57 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-24 15:35:25 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 Ian Hoyle 2003-09-11 03:06:09 EDT
Description of problem:

My up2date process seemed to stop part way through contacting RHN for new 
packages today.

A few hours later I was contacted by my network team saying that my box was 
sending 1000's of packets at our corporate web proxy, opening but not closing 
sessions, looking like a denial of service attack:

###

Ian,
I think the workstation 134.18.124.31 may be sending a Dos at the Netcache. 
Below is some of the output from a netdiag. Can Network services block this IP 
from reacing the Netcache ????

The Netcache memory is being overloaded

egards
Nicholas


msproxy7.8080         elmo.bhpbilliton.58913   5840      0   8593      0 
CLOSE_WAI T msproxy7.8080         elmo.bhpbilliton.58912   5840      0   
8593      0 CLOSE_WAI T msproxy7.8080         elmo.bhpbilliton.58911   
5840      0   8593      0 CLOSE_WAI T msproxy7.8080         
elmo.bhpbilliton.58910   5840      0   8593      0 CLOSE_WAI T 
msproxy7.8080         elmo.bhpbilliton.58909   5840      0   8593      0 
CLOSE_WAI T msproxy7.8080         elmo.bhpbilliton.58908   5840      0   
8593      0 CLOSE_WAI T msproxy7.8080         elmo.bhpbilliton.58907   
5840      0   8593      0 CLOSE_WAI T msproxy7.8080         
elmo.bhpbilliton.58906   5840      0   8593      0 CLOSE_WAI T 
msproxy7.8080         elmo.bhpbilliton.58905   5840      0   8593      0 
CLOSE_WAI T msproxy7.8080         elmo.bhpbilliton.58904   5840      0   
8593      0 CLOSE_WAI T msproxy7.8080         elmo.bhpbilliton.58903   
5840      0   8593      0 CLOSE_WAI T msproxy7.8080         
elmo.bhpbilliton.58902   5840      0   8593      0 CLOSE_WAI T 
msproxy7.8080         134.18.124.31.58901     5840      0   8593      0 
CLOSE_WAIT
msproxy7>
msproxy7>
####

Even after subsequent reboots the problem was still present. As soon as daemon 
started (I'm guessing rhnsd), the netwrk flooding started up again causing me 
to pull the plug (literally!!) from my box to the network.

I have done a "chkconfig rhnsd off" and rebooted and the problem disappeared.

Are there any issues/bugs with rhnsd that have been reported similar to this??

   Ian

--------------

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


How reproducible:

until I turned off rhnsd, every time I rebooted.

---------------


Steps to Reproduce:
1.
2.
3.
    
Actual results:


Expected results:


Additional info:
Comment 1 Mark J. Cox (Product Security) 2003-09-11 12:37:51 EDT
Can you tell us what version of up2date you are running? ("rpm -q up2date")
Comment 2 Ian Hoyle 2003-09-11 17:00:27 EDT
The version of up2date I'm running is

[root@elmo root]# rpm -q up2date
up2date-3.1.23.2-1
[root@elmo root]# 
Comment 3 Mihai Ibanescu 2003-09-12 15:32:56 EDT
Also, can you do:

rpm -q rhnlib

Does the problem exist if you run just up2date, or rhn_check?

Comment 4 Adrian Likins 2003-09-12 15:47:25 EDT
Hows up2date configured? proxy settings, etc?
Comment 5 Adrian Likins 2003-09-15 12:51:55 EDT
Havent ever seen any reports of this kind of behaviour before,
and just setting it up to talk to a proxy doesnt show this
for me.

So I'm looking for any info that might be useful in
reproducing this. What kind of proxy server? Any
weird DNS or routing issues to keep in mind? firewall
rules?
Comment 6 Ian Hoyle 2003-09-15 17:28:44 EDT
[root@elmo root]# rpm -q rhnlib
rhnlib-1.0-4

The Internet connection uses a proxy on port 8080.
The proxy is a Network Appliance NetCache that is doing NTLM based auth. I had 
no problems using up2date (it runs fine manually) for a couple of weeks and 
browsing using Mozilla works also.

My user credentials look like:

user:      domain\user
password:  somepassword


It could have been rhn_check that was the culprit (run by rhnsd???).

I can see these errors in the up2date log file:

[Wed Sep 10 19:14:24 2003] up2date updating login info
[Wed Sep 10 19:14:24 2003] up2date logging into up2date server
[Wed Sep 10 19:14:51 2003] up2date A socket error occurred: (-3, 'Temporary 
failure in name resolution'), attempt #1
[Wed Sep 10 19:15:44 2003] up2date A socket error occurred: (-3, 'Temporary 
failure in name resolution'), attempt #1
[Wed Sep 10 19:16:16 2003] up2date A socket error occurred: (-3, 'Temporary 
failure in name resolution'), attempt #2
[Wed Sep 10 19:16:36 2003] up2date A socket error occurred: (-3, 'Temporary 
failure in name resolution'), attempt #3
[Wed Sep 10 19:16:39 2003] up2date A socket error occurred: (-3, 'Temporary 
failure in name resolution'), attempt #2
[Wed Sep 10 19:16:42 2003] up2date A socket error occurred: (-3, 'Temporary 
failure in name resolution'), attempt #4
[Wed Sep 10 19:16:42 2003] up2date A socket error occurred: (-3, 'Temporary 
failure in name resolution'), attempt #3
[Wed Sep 10 19:16:47 2003] up2date A socket error occurred: (-3, 'Temporary 
failure in name resolution'), attempt #5
[Wed Sep 10 19:16:47 2003] up2date Error communicating with server. The 
message was:
Temporary failure in name resolution
[Wed Sep 10 19:16:47 2003] up2date A socket error occurred: (-3, 'Temporary 
failure in name resolution'), attempt #4
[Thu Sep 11 00:42:14 2003] up2date updating login info
[Thu Sep 11 00:42:14 2003] up2date logging into up2date server
[Thu Sep 11 00:42:15 2003] up2date successfully retrieved authentication token 
from up2date server

Perhaps the process got into a weird state in the presence of interrupted DNS 
resolution?


Hope that helps.
Comment 7 Josh Bressers 2004-06-18 17:43:06 EDT
Removing security severity; This is not a security issue.
Comment 8 Adrian Likins 2004-08-24 15:35:25 EDT
There were some issues with up2adte and rhnlib that could
cause behaviour of this sorts that has since been fixed
(basically, being too aggressive retrying...)


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