[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1193
  • Last Modified:

Red Hat, xinetd, UDP port 686


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
phasevar
Asked:
phasevar
  • 5
  • 4
  • 2
  • +4
1 Solution
 
troopernCommented:
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
 
phasevarAuthor Commented:

I get a connection refused.  But I don't think I can use telnet to connect to a UDP port.
0
 
troopernCommented:
That's true. How stupid of me ;)
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
lbertaccoCommented:
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
 
owensleftfootCommented:
netstat -p will tell you the name of the program which owns the socket.
0
 
shailendra_patankarCommented:
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
 
phasevarAuthor Commented:
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
 
lbertaccoCommented:
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
 
phasevarAuthor Commented:
'rpm -V xinetd' reports this:

S.5....T c /etc/xinetd.conf
0
 
lbertaccoCommented:
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
 
phasevarAuthor Commented:
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
 
lbertaccoCommented:
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
 
Alf666Commented:
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
 
phasevarAuthor Commented:
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
 
egberts7Commented:
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

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 5
  • 4
  • 2
  • +4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now