Re: Tracking down IP's
JD Kitch <adahma@gmx.net> wrote:
> Can anyone tell me what this person is looking for here, and how I
> can find out where this is coming from?
>
> Security Violations
> =-=-=-=-=-=-=-=-=-=
> Dec 31 11:06:47 tower kernel: Packet log: output REJECT eth0 PROTO=17 xx.xx.xxx.xx:61662 172.16.72.113:161 L=106 S=0x00 I=7632 F=0x0000 T=127 (#43)
> Dec 31 11:06:53 tower kernel: Packet log: output REJECT eth0 PROTO=17 xx.xx.xxx.xx:61662 172.16.72.113:161 L=106 S=0x00 I=7712 F=0x0000 T=127 (#43)
> Dec 31 11:06:59 tower kernel: Packet log: output REJECT eth0 PROTO=17 xx.xx.xxx.xx:61662 172.16.72.113:161 L=106 S=0x00 I=7713 F=0x0000 T=127 (#43)
> Dec 31 11:07:06 tower kernel: Packet log: output REJECT eth0 PROTO=17 xx.xx.xxx.xx:61662 172.16.72.113:161 L=106 S=0x00 I=7716 F=0x0000 T=127 (#43)
> Dec 31 11:07:13 tower kernel: Packet log: output REJECT eth0 PROTO=17 xx.xx.xxx.xx:61662 172.16.72.113:161 L=106 S=0x00 I=7724 F=0x0000 T=127 (#43)
> Dec 31 11:07:19 tower kernel: Packet log: output REJECT eth0 PROTO=17 xx.xx.xxx.xx:61662 172.16.72.113:161 L=106 S=0x00 I=7725 F=0x0000 T=127 (#43)
>
> I've been unable to track it down. I've had pages and pages of this
> every hour since early yesterday, always coming from the same IP, to
> the same port.
(First, sorry about the lack of references headers; I wanted to reply to
the original post in the thread, but I'd already deleted it. Cut-n-paste
off the archives on debian's web site.)
Now, to those who asked which tool was generating these log entries: kernel
2.2's firewalling code, as controlled by ipchains(8). (Thus the `kernel'
label.)
However, I'm feeling really stupid about now. I only just noticed (after 3
posts!) that these messages are being generated from an *output* chain,
rather than an input chain. (That, of course, would be why it says `output
REJECT' instead of `input REJECT.') Everything I've said on this thread
has dealt with INPUT chains and is therefore completely irrelevant. <sigh>
(It's still useful, of course, if you get unexplained crud from an input
chain.)
You're not getting scanned, JD. You're actually trying to *send* a packet
to 172.16.72.113, port 161/udp (SNMP), from IP xx.xx.xx.xx, port 61662/udp.
Your firewall rules don't allow this traffic to leave your machine. (If
xx.xx.xx.xx isn't your IP, then you're forwarding it instead---I think. I
can't check that, since I've only got the one machine.)
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
The first and second fields are the name and pid, respectively, of the
program(s) which have this socket open. The next step depends on what you
find there. If you're actually trying to run an SNMP manager, then it
looks like you've misconfigured it. Otherwise, you'll need to revisit your
firewall rules to allow outgoing traffic to the SNMP agents you're trying
to administer. If you're *not* trying to run SNMP, then you may have a
fairly serious problem---somebody may have managed to get onto your system
and run a process that probably shouldn't be there.
I'm a little surprised by the fact that you're trying to send from 61662; I
thought that was a port in the range reserved by the kernel for IP
masquerading. I could be wrong, though, so I wouldn't worry about that too
much.
Also, I *think* I've figured out what the (#43) means. I'm fairly, but not
completely, certain that this is the index number of the ruleset in the
named chain (here, output) which caused the packet to be blocked. This may
be helpful in rewriting your firewall rules. (I do wish that ipchain's log
output format was documented better.)
Sorry for the misinformation,
Richard
Reply to: