?
Solved

Red Hat, xinetd, UDP port 686

Posted on 2004-03-21
15
Medium Priority
?
1,160 Views
Last Modified: 2013-12-15

distro: Red Hat 7.3

When I do a 'netstat -nl' I find UDP port 686 open.  I do an 'lsof | grep UDP' and I find that xinetd has this port open.  I look in /etc/services and find nothing under port 686.  'grep 686 /etc/xinetd.d/*' turns up nothing.  Why is xinetd binding to UDP port 686 and how do I disable that if need be?
0
Comment
Question by:phasevar
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 4
  • 2
  • +4
15 Comments
 
LVL 7

Expert Comment

by:troopern
ID: 10647559
This is what I find that could be using port 686.
hcp-wismar      686/tcp    Hardware Control Protocol Wismar
hcp-wismar      686/udp    Hardware Control Protocol Wismar

Try telnetting to port 686 and check what kind of banner you receieve.
Locally:
telnet localhost 686
Or from a remote machine:
telnet IPADDRESS 686
0
 

Author Comment

by:phasevar
ID: 10647592

I get a connection refused.  But I don't think I can use telnet to connect to a UDP port.
0
 
LVL 7

Expert Comment

by:troopern
ID: 10647604
That's true. How stupid of me ;)
0
Get MongoDB database support online, now!

At Percona’s web store you can order your MongoDB database support needs in minutes. No hassles, no fuss, just pick and click. Pay online with a credit card. Handle your MongoDB database support now!

 
LVL 11

Expert Comment

by:lbertacco
ID: 10647920
Check if you have any non standard services defined in /etc/xinetd.d/ (not that the port may not appear explicitly, so verify if each service should use that port or not)
If you cannot find any, probably either xinetd has been copromised (Verify it with
rpm -V xinetd
assuming your rpm database has not been compronmised too), or one of the services started by xinetd has been compromised.
0
 
LVL 17

Expert Comment

by:owensleftfoot
ID: 10648249
netstat -p will tell you the name of the program which owns the socket.
0
 
LVL 2

Expert Comment

by:shailendra_patankar
ID: 10651566
HI..

Whether ur server is connected to the internet directly..

without any firewall....

if no firewall than someone is try to access that port...

what is show in netstat .... it is establish the connection or time out...

if firewall is there... disable that port and see the effect...

0
 

Author Comment

by:phasevar
ID: 10654467
netstat -p and lsof report the same thing.  The socket is owned by xinetd.

It's a listening UDP socket.  There is no connection to be established.

There is no firewall setup.  I close all unncessary open sockets (which is what led me to this problem) and I use tcpwrappers to deny access to unauthorized hosts.

I haven't been able to find any information as to why xinetd is listening on this port nor how to change it.
0
 
LVL 11

Expert Comment

by:lbertacco
ID: 10656131
Well it's more and more probable that you have a compromised xinetd.
Did you check with: ?
rpm -V xinetd
What does it report?
0
 

Author Comment

by:phasevar
ID: 10659366
'rpm -V xinetd' reports this:

S.5....T c /etc/xinetd.conf
0
 
LVL 11

Expert Comment

by:lbertacco
ID: 10659749
Well that seems ok (or at least the xinetd binary matches the checksum in the database).
Anyway you usually don't need to change xinetd.conf since it's easier to configure services in /etc/xinetd.d. Here xinetd.conf has been changed. Did you already check if you have any service defined for port 686 in /etc/xinetd.conf (besides those in /etc/xinetd.d) ?
0
 

Author Comment

by:phasevar
ID: 10659879
Yes, I edited xinetd.conf.  I just commented out the log_on_success line.

There are no references to port 686 in xinetd.conf.  Other than my comment it's the distribution file.
0
 
LVL 11

Expert Comment

by:lbertacco
ID: 10660025
Weird, well I have redhat 7.3 too.
netstat -nl doesn't report port 686 open.
"rpm -q xinetd" says
xinetd-2.3.9-0.73
"ps auxw|grep xinetd" says
root      1093  0.0  0.4  2116  872 ?        S    10:32   0:00 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
"ls -l /proc/1093/exe (1093 is xinetd PID)" says
/proc/1093/exe -> /usr/sbin/xinetd
Verify that you have the xinetd from /usr/sbin too.
"ls -l /usr/sbin/xinetd" says
-rwxr-xr-x    1 root     root       169755 Oct  2  2002 /usr/sbin/xinetd
and "openssl sha1 /usr/sbin/xinetd" says
SHA1(/usr/sbin/xinetd)= 6c8c700dcb5aa5311099b9e79cfb1e6104b369ec




0
 
LVL 9

Accepted Solution

by:
Alf666 earned 2000 total points
ID: 10661110
You will not find a string "686" in xinetd.d. Each file should contain a service description using it's symbolic name.

e.g. :

service chargen
{
        type            = INTERNAL
        id              = chargen-stream
        socket_type     = stream
        protocol        = tcp
        user            = root
        wait            = no
        disable         = yes
}                        

In this case, the "service chargen" is what you're looking for. xinetd then uses /etc/services to identify that chargen is on port 19.

You should "grep 686 /etc/services", grab whatever you will find here, and grep this in /etc/xinetd.d/*. If you have multiple possibilities, try them all.

You can also check by hand what's activated in your xinetd setup with :
xinetd -d
(providing you have shutdown an existing xinetd with, per example, /etc/init.d/xinetd stop).

At this point, either you find what you're looking for, or you'd rather check your whole system for possible security compromission.
0
 

Author Comment

by:phasevar
ID: 10661569
I shut down xinetd and ran 'xinetd -d' and found that the only service running that was not setup by me was sgi_fam.  I wasn't familiar with sgi_fam so I did some looking around and it appears to be a service to notify programs of file system updates (man fam).  Since this is just a web server, I disabled sgi_fam and now when I do a 'netstat -nl' the port is gone.

I still don't quite understand it since grepping /etc/services returns nothing for port 686.  And this same service seems to be causing UDP port bindings on my other servers, but on different ports (not 686).

0
 

Expert Comment

by:egberts7
ID: 11129546
That is easy.

If you strace or gdb the xinetd, you will find that sgi-fam is the one creating the rogue UDP socket.

This only happens when you dont have portmapper running (do 'service portmapper start' for RedHat).

Once the portmapper is running, the xinetd no longer errors out at the pmap_set() function call and thus no longer creates the rogue UDP socket.
0

Featured Post

New feature and membership benefit!

New feature! Upgrade and increase expert visibility of your issues with Priority Questions.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I am a long time windows user and for me it is normal to have spaces in directory and file names. Changing to Linux I found myself frustrated when I moved my windows data over to my new Linux computer. The problem occurs when at the command line.…
Linux users are sometimes dumbfounded by the severe lack of documentation on a topic. Sometimes, the documentation is copious, but other times, you end up with some obscure "it varies depending on your distribution" over and over when searching for …
Learn how to get help with Linux/Unix bash shell commands. Use help to read help documents for built in bash shell commands.: Use man to interface with the online reference manuals for shell commands.: Use man to search man pages for unknown command…
This demo shows you how to set up the containerized NetScaler CPX with NetScaler Management and Analytics System in a non-routable Mesos/Marathon environment for use with Micro-Services applications.
Suggested Courses
Course of the Month10 days, 16 hours left to enroll

770 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question