Solved

Red Hat, xinetd, UDP port 686

Posted on 2004-03-21
15
1,108 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
  • 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
 
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
Get up to 2TB FREE CLOUD per backup license!

An exclusive Black Friday offer just for Expert Exchange audience! Buy any of our top-rated backup solutions & get up to 2TB free cloud per system! Perform local & cloud backup in the same step, and restore instantly—anytime, anywhere. Grab this deal now before it disappears!

 
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 500 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

Better Security Awareness With Threat Intelligence

See how one of the leading financial services organizations uses Recorded Future as part of a holistic threat intelligence program to promote security awareness and proactively and efficiently identify threats.

Join & Write a Comment

Suggested Solutions

Daily system administration tasks often require administrators to connect remote systems. But allowing these remote systems to accept passwords makes these systems vulnerable to the risk of brute-force password guessing attacks. Furthermore there ar…
I. Introduction There's an interesting discussion going on now in an Experts Exchange Group — Attachments with no extension (http://www.experts-exchange.com/discussions/210281/Attachments-with-no-extension.html). This reminded me of questions tha…
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…
Learn how to find files with the shell using the find and locate commands. Use locate to find a needle in a haystack.: With locate, check if the file still exists.: Use find to get the actual location of the file.:

708 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

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now