nmap and a floating mystery port

slakmagik · 03-20-2005, 02:15 AM

I get to betray my ignorance again. I was playing around with Gnome and the trash applet being stupid (of all things) led me to see if enabling fam (and thus portmap) would wake it up. It did, but it bugged the hell out of me to be running this crap just to have the doohickeys and file managers keep up with filesystem changes. So I installed nmap and ran xnmap and punched a bunch of buttons. In particular, 'nmap -sU -sR -p- -PI -PT -v [against localhost and ip#]' includes '[number]/udp open unknown'. I read
http://www.linuxquestions.org/questi...04/01/1/130097
http://www.linuxquestions.org/questi...03/11/3/117263
http://www.linuxquestions.org/questi...05/01/1/273848
http://www.redhat.com/docs/manuals/l...ver-ports.html
and ran all those commands. The problem is, *every* time I run nmap, it reports a *different* [number] that is open/unknown and none of these commands (and variations) return anything. The one thing that sounds hopeful is that I am behind a broadband router - can this be opening and closing ports at random as a means of communication or have I been cracked? I set the thing up a long time ago and it was a nightmare I've forgotten, so I'm not sure. Like I've posted before, the only net I want is between me and mozilla for my websites and email. I don't know anything else about that sphere of operations.

Second question - it was easy enough to make sure famd only listened locally but how do I insure portmap is as safe as I can make it? I wasn't able to find that. I killed both processes as soon as I ensured that they were working but that portmap/rpc was showing to nmap.

Running Arch at the moment, with two independent boxes behind the same router. Intellinet somesuch. Thanks.

Oh - and about /etc/hosts.deny - everything's set to refuse but isn't there a 'drop' or 'ignore' setting or something? I shouldn't even appear in any way shape or form if I can.

Capt_Caveman · 03-20-2005, 11:40 AM

Since you are scanning yourself, you're actually seeing the source port that the nmap is being launched from. That's why it changes each time you scan and is always an ephemeral port. You can prove this to yourself. Fireup tcpdump to listen on localhost (tcpdump -i lo) and then scan localhost again. You'll notice that the 'mystery port" is always the source port that nmap is using:

Code:

tcpdump -i lo host 127.0.0.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes

12:08:04.362725 IP localhost.localdomain.44936 > localhost.localdomain.63912: UDP, length 0
12:08:04.362736 IP localhost.localdomain > localhost.localdomain: icmp 36: localhost.localdomain udp port 63912 unreachable
12:08:04.460431 IP localhost.localdomain.[/b]44936[/b] > localhost.localdomain.12825: UDP, length 0
12:08:04.460467 IP localhost.localdomain > localhost.localdomain: icmp 36: localhost.localdomain udp port 12825 unreachable
12:08:04.460506 IP localhost.localdomain.44936 > localhost.localdomain.63410: UDP, length 0
12:08:04.460516 IP localhost.localdomain > localhost.localdomain: icmp 36: localhost.localdomain udp port 63410 unreachable
12:08:04.460549 IP localhost.localdomain.44936 > localhost.localdomain.60278: UDP, length 0
12:08:04.460558 IP localhost.localdomain > localhost.localdomain: icmp 36: localhost.localdomain udp port 60278 unreachable
12:08:04.460588 IP localhost.localdomain.44936 > localhost.localdomain.43910: UDP, length 0

--In the other console window---
root@beta ~]# nmap -sU -p- -sR -PI -PT -v 127.0.0.1

Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2005-03-20 12:07 EST
Initiating UDP Scan against localhost.localdomain (127.0.0.1) [65535 ports] at 12:07
Discovered open port 44936/udp on 127.0.0.1
The UDP Scan took 19.73s to scan 65535 total ports.
Initiating RPCGrind Scan against localhost.localdomain (127.0.0.1) at 12:08
The RPCGrind Scan took 0.51s to scan 1 ports on localhost.localdomain (127.0.0.1).
Host localhost.localdomain (127.0.0.1) appears to be up ... good.
Interesting ports on localhost.localdomain (127.0.0.1):
(The 65532 ports scanned but not shown below are in state: closed)
PORT      STATE         SERVICE     VERSION
68/udp    open|filtered dhcpclient
631/udp   open|filtered unknown
44936/udp open          unknown
Nmap run completed -- 1 IP address (1 host up) scanned in 21.334 seconds

So the scan is just "seeing itself" in a way. If you scan a different system, you'll notice you don't ever see a "mystery port" appear.

slakmagik · 03-20-2005, 11:55 AM

Argh.

Like 'ps aux | grep foo' will usually return a result of at least 'ps aux | grep foo' whether there's an actual 'foo' or not. Nmap's returning itself. Makes perfect sense and that's what it does, of course. Thanks. No idea why I've never noticed this before, though.

Thanks for that.

Still curious about the portmap issue - is it advisable to just run it? If hosts.allow is blank and hosts.deny is all, that's about as good as I can get it?

Capt_Caveman · 03-20-2005, 08:36 PM

Like 'ps aux | grep foo' will usually return a result of at least 'ps aux | grep foo' whether there's an actual 'foo' or not..
Yes, very similar to that.

Still curious about the portmap issue - is it advisable to just run it? If hosts.allow is blank and hosts.deny is all, that's about as good as I can get it?
Personally I don't like portmap and I really don't think FAMd is usefull enough to justify having portmap running. Portmap's security history is pretty spotty so I'd only run it if necessary (if I had to run NFS for example). If you are going to run it, then I'd definitely recommend restricting access with tpc wrappers or firewalling it with iptables. Though with tcp wrappers you need to make sure that portmap is either run through inetd/xinetd and uses tcpd or make sure that portmap was compiled with liwrap support. This can vary from distro to distro and I'm not sure how slack or arch have configured it.

slakmagik · 03-21-2005, 02:46 AM

Quote:

Originally posted by Capt_Caveman
Personally I don't like portmap and I really don't think FAMd is usefull enough to justify having portmap running. Portmap's security history is pretty spotty so I'd only run it if necessary (if I had to run NFS for example). If you are going to run it, then I'd definitely recommend restricting access with tpc wrappers or firewalling it with iptables. Though with tcp wrappers you need to make sure that portmap is either run through inetd/xinetd and uses tcpd or make sure that portmap was compiled with liwrap support. This can vary from distro to distro and I'm not sure how slack or arch have configured it.

Me either.

On Slack I never run anything networking-related but dhcpcd. Portmap and the like aren't even installed. On my little homegrown system, it's the same, as far as that goes. I don't like daemons and 'services' and open ports on principle. Arch is just for playing around with stuff I don't ordinarily touch. And that's about what I figured as far as the pros and cons though I'd no idea of the details. That gives me something to 'man' and 'google' anyway, instead of flailing around at random. I'll probably skip it but I'll look into it some more. Stuff like rox and nedit just poll, I think, and find out the 'file alterations' themselves. That's how it ought to be, to me. Anyway - again, thanks very much.