On Fri, May 31, 2002 at 09:55:14AM +0200, [EMAIL PROTECTED] wrote:
> yesterday looking on log of an host in my lan I saw some packets direct
> to this port 32785.
Not all port numbers are hard-wired to correspond to a particular
service. Port numbers that large are generally port numbers that the OS
assigned to some program that didn't ask for a particular port number;
such a program might be a *client* of some service.
> after this I search for a program that run on this port and I find "snmpXdmid"
> with number of program "100249" this program on solaris run on this way:
>
> rpcinfo -p | grep 100249
> 100249 1 udp 32785
> 100249 1 tcp 32786
ONC RPC services are generally not assigned fixed port numbers; an ONC
RPC client contacts the ONC RPC portmapper to get the port number (or
transport address) for a service with a given program number.
(The only exceptions are the portmapper, which has a fixed port number
because you can't contact the portmapper to find the port number at
which to contact the portmapper if you don't already know the port
number at which to find the portmapper, and NFS.)
As such, the fact that program 100249 happens to have UDP port 32785 and
TCP port 32786 on the machine on which that "rpcinfo" command was run
doesn't mean that port is permanently assigned to that program; if I run
it here, I get
hostname$ rpcinfo -p | egrep 100249
100249 1 udp 33298
100249 1 tcp 32919
> Also: fuser -v -n tcp/udp:32785 no response = null
> and: lsof -i tcp/udp:32785 no response = null
Were those run on Solaris (the Solaris 8 "fuser" doesn't have "-v" or
"-n" options), or on some other OS?
> The problem it's that I haven't this program in my lan no machine hold this
> service and again i'm not use "solaris" also if think that linux can offer
> this service.
> Now this is the output :
>
> 14:40:28.888396 192.168.100.3.32785 > my.host.priv.ipp: P 3609975255:3609975286(31)
> ack 13877360 win 17376 <nop,nop,timestamp 76452 10640185> (DF)
Well, "ipp" might be the Internet Printing Protocol, which is an
HTTP-based protocol for remote printing:
http://www.pwg.org/ipp/
CUPS:
http://www.cups.org/
support and uses IPP, so if you're running CUPS (or some other printing
software that uses IPP) client software on 192.168.100.3, and running
CUPS or some other IPP server software on "my.host.priv", and it
supports network printing to some printer attached to "my.host.priv",
perhaps some program on 192.168.100.3 machine was printing a file to a
printer on "my.host.priv", and that program happened to get the TCP port
number 32785 assigned to the socket it was using to communicate with
the IPP server on "my.host.priv".
IPP, by default, uses port 631; if you're not running CUPS or some other
IPP server on "my.host.priv", perhaps some *other* TCP-based server
happened to get assigned that port number.
If you ran the "fuser" and "lsof" commands on 192.168.100.3, perhaps the
program that happened to be using port 32785 had finished whatever it
was doing, and exited, by the time you ran the "fuser" and "lsof"
commands.
(The "fuser" man page on at least one Red Hat machine here seems to
imply that "-n" only checks *local* port numbers:
-n space
Select a different name space. The name spaces file
(file names, the default), udp (local UDP ports),
and tcp (local TCP ports) are supported. For
ports, either the port number or the symbolic name
can be specified. If there is no ambiguity, the
shortcut notation name/space (e.g. name/proto) can
be used.
If that's true, you'd have to run it on 192.168.100.3, not
"my.host.priv", to see any processes.)
> I'am paranoid to think that this would be an attempt to scan my ports to
> the search of some exploit? "in this case "snmpXdmid" produce a buffer
> overflow,
Well, yes, there *is* a buffer overflow risk for snmpXdmid:
http://www.cert.org/advisories/CA-2001-05.html
but that appear to be a Solaris-specific program (unless somebody's
written an SNMP-to-DMI mapping daemon, compatible with Sun's snmpXdmid,
for other OSes), and, as I said, snmpXdmid, like other ONC RPC services,
does not have a fixed port number.
> Or is Normal traffic??????
It's probably just normal traffic.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
