JD Kitch <[EMAIL PROTECTED]> 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
