Strange listening ports
Daniel Fages
Juan Leon Lahoz Garcia (sp...@vendimiario.tecsidel.es) wrote:
: The numbers are 2049 and 911.
Port 2049 is NFS, no ?
For 911, I don't know.
--
*****************************************
* Daniel Fages --- INSA 5IF *
* E-Mail : dfa...@ifhamy.insa-lyon.fr *
*****************************************
Juan Leon Lahoz Garcia
I run a port scanner in my linux box and I found two listening
ports that I dont expect to be. I check the numbers at /etc/services and
they dont appear. In my etc/inetd.conf I only have 3 entries, and I don't
run X. netstat -a show this listening ports also.
The numbers are 2049 and 911.
How can I find out the daemons listening at that port ?
Does anybody know what are that ports supposed to do ?
How can I disable them ?
Thanks for your time.
(please, CC your answer to my email, my news server is ssslow)
Roger Books
Daniel Fages (dfa...@ifhamy.insa-lyon.fr) wrote:
: Juan Leon Lahoz Garcia (sp...@vendimiario.tecsidel.es) wrote:
: : The numbers are 2049 and 911.
: Port 2049 is NFS, no ?
2049 is NFS, yes ?
: For 911, I don't know.
Could this be one of the "r" services?
Roger
----------------------------------------------------------------------
The reply-to: address in the headers is a valid address, if you want
to send me e-mail just hit reply and it should work fine. If your
newsreader is broken and can't deal with that then send your e-mail
to: 970805022...@mail.state.fl.us
----------------------------------------------------------------------
Larry Doolittle
Daniel Fages (dfa...@ifhamy.insa-lyon.fr) wrote:
: Juan Leon Lahoz Garcia (sp...@vendimiario.tecsidel.es) wrote:
: : The numbers are 2049 and 911.
: Port 2049 is NFS, no ?
: For 911, I don't know.
That's probably the kernel "connected" to an external NFS file
system. I know for every NFS volume I mount, I get another udp
port below 1024 engaged. I suppose it's the mount(1) program
that opens the port, and then hands it off to the kernel.
The /proc filesystem doesn't confirm this anywhere.
My quick hack (in perl) to look at the port/process mapping is
available at
http://recycle.jlab.org/~ldoolitt/stuff/socklist
Hope this helps.
- Larry Doolittle ldoo...@jlab.org
Kurt M. Hockenbury
lsof (LiSt Open Files)
<ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/>
-Kurt
Scotty
2049 is nfsd.. From the man-page:
[...]
-P portnum or --port portnum
Makes nfsd listen on port portnum instead of the default port 2049.
[...]
Don't run rpc.nfsd if you don't want it open.
911 I'm not sure about..
On 19 Sep 1997, Juan Leon Lahoz Garcia wrote:
> The numbers are 2049 and 911.
> How can I find out the daemons listening at that port ?
Jared Roberts
Scotty wrote:
>
> 911 I'm not sure about..
>
Well, it's not in my /etc/services -- I'd say its something to be very
suspicious about, first of all, of course, because of the number itself
("911" being the telephone number in the US for emergency services --
sounds odd that it just happens to be a port that's active and yet
nobody has heard of it.) Second of all, anything listening on a port
<1024 must be setuid root to run. So if it IS an evil program, they've
already got you rooted. It's probably a bad idea to telnet to that port
to "see what it does", but being the curious, uncareful sort (who has
the luxury of a private Linux machine), I have to admit I'd do it
anyway. Can't say I'd actually RECOMMEND that course of action tho.
--Jared Roberts
wj...@email.byu.edu
Roger Books
Jared Roberts (wj...@email.byu.edu) wrote:
: Scotty wrote:
: >
: > 911 I'm not sure about..
: >
: already got you rooted. It's probably a bad idea to telnet to that port
: to "see what it does", but being the curious, uncareful sort (who has
: the luxury of a private Linux machine), I have to admit I'd do it
: anyway. Can't say I'd actually RECOMMEND that course of action tho.
If it is a production system do the telnet AFTER a backup.
Larry Doolittle
Roger Books (bo...@booksr.dms.state.fl.us) wrote:
: : > 911 I'm not sure about..
: : It's probably a bad idea to telnet to that port
: : to "see what it does", but being the curious, uncareful sort (who has
: : the luxury of a private Linux machine), I have to admit I'd do it
: : anyway. Can't say I'd actually RECOMMEND that course of action tho.
: If it is a production system do the telnet AFTER a backup.
In most cases those sockets will be udp - it's kinda hard to
telnet to a udp port.
I can't believe I'm the only one reading this newsgroup who has
figured out where those low numbered ports come from on a Linux
box. They are generated by the "mount -t nfs" command and are
handed off to the kernel for use in a client NFS file system;
hence they stick around after the mount process has terminated,
and they have no apparent owner. In my copy of mount-2.5l,
the relevant code is in nfs_mount.c, where it calls bindresvport(3)
In my first posting, I mentioned my "poor mans lsof" that can
trace most socket owners, although not this one - I have since
gotten 63 hits at
http://recycle.jlab.org/~ldoolitt/stuff/socklist
ObSecurity: can an attacker do anything nasty to a system by sending
packets to this port? Forged source or otherwise?
- Larry Doolittle ldoo...@jlab.org
P.S. Note to Linux maintainers: man pages for the libc function
bindresvport(3) appear to be missing, at least on my RedHat 4.2 system.
Jim White
Seeing the title of this thread, I've got a question:
How can root monitor a port, a tty, a cua? etc.?
Jim
Kurt M. Hockenbury
Jim White (tz...@usa.net) wrote:
: Seeing the title of this thread, I've got a question:
: How can root monitor a port, a tty, a cua? etc.?
Depends on what you mean by 'monitor'. If you want to know what program(s)
have any of those open, the answer is lsof:
<ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/>
If you want to monitor the data flowing through, use a sniffer for IP port
stuff. Serial devices would need some kernel-level monitoring program,
as best I can figure, or some special monitoring hardware at the serial
port.
Hope this helps,
-Kurt
Matthew Wilcox
Scotty (sco...@dilbert.netset.com) wrote:
: 2049 is nfsd.. From the man-page:
: [...]
: -P portnum or --port portnum
: Makes nfsd listen on port portnum instead of the default port 2049.
: [...]
: Don't run rpc.nfsd if you don't want it open.
: 911 I'm not sure about..
It could well be the portmapper, the mount daemon or another rpc based
service. try running rpcinfo to find out.
--
"I was absolutely horrified to see a book entitled 'C++ for dummies'. What
is the potential market for this book? What programmer considers themself
to be a dummy? Who wants to run code written by a dummy? And perhaps
more importantly, someone who *considers themselves* to be a dummy?"
Tim Newsham
Larry Doolittle (ldoo...@recycle.jlab.org) wrote:
: I can't believe I'm the only one reading this newsgroup who has
: figured out where those low numbered ports come from on a Linux
: box. They are generated by the "mount -t nfs" command and are
: handed off to the kernel for use in a client NFS file system;
: hence they stick around after the mount process has terminated,
: and they have no apparent owner. In my copy of mount-2.5l,
: the relevant code is in nfs_mount.c, where it calls bindresvport(3)
: ObSecurity: can an attacker do anything nasty to a system by sending
: packets to this port? Forged source or otherwise?
yes. At least in some versions of the system. If you send
a packet to this port, it gets queued and is read on
after the next RPC request (i.e. NFS operation) when
the kernel is looking for an NFS reply. If you send
a 1 byte packet to the port, the kernel reads it and prints
an error message about a short RPC read. The code has an
error in it and never discards the packet so the next time
around it reads the same thing and again prints the message.
The end result is that the system loops indefinitely printing
messages and userland never runs.
I'm not sure if this has been fixed since I didn't have
a recent linux system to test against.
: - Larry Doolittle ldoo...@jlab.org
Tim N.