Re: Tracking down IP's
Lo, on Sunday, December 31, JD Kitch did write:
> > Now, find out *who's* sending this traffic. Make sure you've got the
> > lsof-2.2 package installed. As root, run
> >
> > lsof | grep 61662 | grep -i udp
>
> I do have that package, but this command turned up no output.
Uh oh. And you're still getting these log messages? That's probably not
good. It's possible that lsof could slip through the cracks, so to speak,
but it's pretty unlikely.
> Just yesterday I got another machine connected to this one via a
> second nic, and I have a windows machine attched that I'm
> masquerading for, but that is not the IP i configured that machine
> to be. I'm certainly not knowingly running anything for SNMP, hell,
> I don't even know what it is. :P Any ideas, what I might be running
> that would cause this?
I've not worked with masquerading much; I use ipchains primarily for
firewalling. It's possible (though, I think, fairly unlikely) that this
record is due to packets you're relaying for the Windows box. That's easy
to test:
ipchains -I input 1 -s <windows-box's-IP> -p udp -d 0.0.0.0/0 161 -l -j DENY
will block all traffic from the windows machine to port 161/udp ANYWHERE,
as it enters your Debian machine. If you stop getting these REJECT
messages on your output chain and start getting DENY messages on your input
chain, then that's the deal. If that's the case, then the Windows box is
likely running some sort of SNMP software, so you'll need to consult your
local Windows guru for further instructions.
Otherwise, it's not that. Yank the rule:
ipchains -D input 1
I'm not very familiar with the Debian packages, as yet. The only ones I
know of that deal with SNMP at all are snmp (the client), snmpd (the
server), and associated libraries. It's been a while since I've done SNMP,
but I don't think that either of these two packages would cause this kind
of behavior; the port numbers look bogus.
SNMP is the Simple (ahem!) Network Management Protocol; it's basically
intended for monitoring and administering various devices across the
network. The SNMP folks redid the terminology for no adequately-explained
reason (although I think the telephone companies may have had their fingers
in this pie)---rather than client/server, they have manager/agent. Sorta
makes sense, but there's no reason to come up with new terms.
Anyway: manager (think network administrator sitting at a console watching
his network) sends out a query to one of the agents, which responds with
the requested data. The manager also has the ability to write to the
agents (drop this route, reboot yourself), and there are provisions for
allowing the agents to send asynchronous notifications to the manager
(though those typically use port 162/udp on the manager side). The data
supplied by each agent varies from machine to machine, but it typically
contains stuff like network performance metrics (# dropped packets),
network configuration (routing tables), and so forth.
It's been some time since I've worked with SNMP (I actually had to port a
manager, developed in-house, from Solaris <yuk> to Windows NT <double
yuk>), so the details are a little foggy. The agents (== servers) do have
to listen on port 161/udp, but I don't know that there's any requirement
that the managers use a specific port. Likewise, I think the agents can
send their response out any port, but 99 times out of 100, they'll just use
161/udp, since they've already got it open. Since you seem to be sending
*to* port 161, that would suggest that you (or the windows box) is acting
as a manager. That's not generally something that runs unless you
specifically start it, though.
Here's a thought---try installing ethereal, run it as root, and see if you
can't snoop the packets that are causing this message. Filter on
destination IP and port; unfortunately, I don't remember the details of
ethereal's filter syntax. There's also a good chance you'll have to
install libsnmp for the decode to work.
Then, drop the ipchains rule that's blocking this traffic and get a record
of what exactly is going on here. Send that along, and we'll see if we
can't figure out what's happening. (Once you've finished with ethereal,
you'll probably want to reload the rule.)
Good luck,
Richard
Reply to: