Re: Tracking down IP's
On Sun, Dec 31, 2000 at 02:30:25PM -0600, Richard Cobbe wrote: > Either way, it's still a private IP address range. NOBODY should let > packets with one of these addresses, either as source or destination, cross > a network boundary. If the ISP is getting this traffic from its upstrea > provider, it should configure the router between it and the provider to > drop all private address ranges, and let the provider know it's leaking > private IPs. Hmmm. Wish my ISP followed those rules. I can root around their 10.x.x.x network without problems. And a friend on Qwest/USWest was able to do the same. I originally became curious about it when I realized that traces outbound show the 10.x.x.x network and my DSL device is configured in a layer-2 bridging mode. Someone was VERY lazy in their network design meetings. Tsk tsk. Betcha' the router jocks at both places have CCNA certifcations or higher from Cisco too. Boy howdy! -- Nate Duehr <[EMAIL PROTECTED]> GPG Key fingerprint = DCAF 2B9D CC9B 96FA 7A6D AAF4 2D61 77C5 7ECE C1D2 Public Key available upon request, or at wwwkeys.pgp.net and others.
Re: Tracking down IP's
Looks like HP OpenView or some other network management tool with auto-discovery turned on is wasting bandwidth on your corporate network. (And I say that because...) 161 is SNMP's port number. It's happening at regular intervals. 172.16.0.0/20 is private address space reserved IP's. And... I've seen the same thing in my logs at work when someone misconfigured HP OpenView. On Sun, Dec 31, 2000 at 12:16:59PM -0700, JD Kitch 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=0x 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=0x 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=0x 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=0x 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=0x 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=0x 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. > > TIA, > jdk -- Nate Duehr <[EMAIL PROTECTED]> GPG Key fingerprint = DCAF 2B9D CC9B 96FA 7A6D AAF4 2D61 77C5 7ECE C1D2 Public Key available upon request, or at wwwkeys.pgp.net and others.
Re: Tracking down IP's
On Sun, Dec 31, 2000 at 08:32:48PM -0600, Richard Cobbe wrote: > 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 -p udp -d 0.0.0.0/0 161 -l -j DENY Thanks to everyone for all the assistance. I actually took the lazy way out on this one. Once Richard explained SNMP, it made total sense that it was coming from the attached windows machine, since it was my "corperate" laptop which is typically connected at work to the office LAN. So, I just disconnected the laptop, and sure enough all the messages stopped. Thanks again!! jdk
Re: Tracking down IP's
On Sun, Dec 31, 2000 at 08:32:48PM -0600, Richard Cobbe wrote: > 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. No, that's entirely expected behavior. 61662 was the *source* port of the traffic in the original post. 161 (SNMP) was the destination port. The protocol was UDP, which is stateless. So the process sending the UDP traffic doesn't keep port 61662 open. Nothing at all to worry about Had 61662 been listed as the destination port (and had the original poster read the ipchains log output correctly) then there might have been something to be concerned about. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpk8dorh6EhI.pgp Description: PGP signature
Re: Tracking down IP's
On Tue, Jan 02, 2001 at 02:09:20AM -0600, will trillich wrote: > i've got something quite similar to this, but mine's on INPUT-- > > Jan 2 01:18:48 server kernel: Packet log: input DENY eth0 PROTO=1 > 172.156.51.114:10 224.0.0.2:0 L=28 S=0x00 I=8964 F=0x T=128 (#9) > Jan 2 01:18:51 server kernel: Packet log: input DENY eth0 PROTO=1 > 172.156.51.114:10 224.0.0.2:0 L=28 S=0x00 I=9220 F=0x T=128 (#9) > Jan 2 01:20:07 server kernel: Packet log: input DENY eth0 PROTO=1 > 172.167.37.113:10 224.0.0.2:0 L=28 S=0x00 I=33028 F=0x T=128 (#9) > Jan 2 01:20:10 server kernel: Packet log: input DENY eth0 PROTO=1 > 172.167.37.113:10 224.0.0.2:0 L=28 S=0x00 I=34308 F=0x T=128 (#9) > Jan 2 01:20:13 server kernel: Packet log: input DENY eth0 PROTO=1 > 172.167.37.113:10 224.0.0.2:0 L=28 S=0x00 I=34564 F=0x T=128 (#9) This is multicast traffic. 224.0.0.2 means "all routers on this subnet". This is probably router discovery traffic; I'd bet if you nmap (with tcp fingerprint) 172.167.37.113 you'll find it's a router. btw, unless you editted it, 172.167.37.113 is not a private address (though someone might be laboring under the illusion that it is). RFC 1918 says 172.16.0.0 thru 172.31.255.255 are reserved for private networks. ] [EMAIL PROTECTED]:~$ whois -h rs.arin.net 172.167 ] America Online, Inc. (NETBLK-AOL-172BLK) ]12100 Sunrise Valley Drive ]Reston, VA 20191 ]US ] ]Netname: AOL-172BLK ]Netblock: 172.128.0.0 - 172.185.255.255 ]Maintainer: AOL ] ]Coordinator: ] America Online, Inc. (AOL-NOC-ARIN) [EMAIL PROTECTED] ] 703-265-4670 ] ]Domain System inverse mapping provided by: ] ]DAHA-01.NS.AOL.COM 152.163.159.233 ]DAHA-02.NS.AOL.COM 205.188.157.233 ] ]ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE ] ]Record last updated on 21-Nov-2000. ]Database last updated on 1-Jan-2001 18:15:35 EDT. ] ] The ARIN Registration Services Host contains ONLY Internet ] Network Information: Networks, ASN's, and related POC's. ] Please use the whois server at rs.internic.net for DOMAIN related ] Information and whois.nic.mil for NIPRNET Information. How about that :) -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Inc. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgpVSbWkpF0WD.pgp Description: PGP signature
Re: Tracking down IP's
On Sun, Dec 31, 2000 at 05:25:54PM -0600, Richard Cobbe wrote: > 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=0x 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=0x 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=0x 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=0x 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=0x 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=0x T=127 > > (#43) > > 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.) > 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.) i've got something quite similar to this, but mine's on INPUT-- Jan 2 01:18:48 server kernel: Packet log: input DENY eth0 PROTO=1 172.156.51.114:10 224.0.0.2:0 L=28 S=0x00 I=8964 F=0x T=128 (#9) Jan 2 01:18:51 server kernel: Packet log: input DENY eth0 PROTO=1 172.156.51.114:10 224.0.0.2:0 L=28 S=0x00 I=9220 F=0x T=128 (#9) Jan 2 01:20:07 server kernel: Packet log: input DENY eth0 PROTO=1 172.167.37.113:10 224.0.0.2:0 L=28 S=0x00 I=33028 F=0x T=128 (#9) Jan 2 01:20:10 server kernel: Packet log: input DENY eth0 PROTO=1 172.167.37.113:10 224.0.0.2:0 L=28 S=0x00 I=34308 F=0x T=128 (#9) Jan 2 01:20:13 server kernel: Packet log: input DENY eth0 PROTO=1 172.167.37.113:10 224.0.0.2:0 L=28 S=0x00 I=34564 F=0x T=128 (#9) using the "#9 = number within ruleset" theory, and with ruleset as follows: # ipchains -nL Chain input (policy DENY): target prot opt sourcedestination ports ACCEPT all -- 0.0.0.0/00.0.0.0/0 n/a DENY all l- 127.0.0.0/8 0.0.0.0/0 n/a ACCEPT all -- 192.168.0.0/24 0.0.0.0/0 n/a ACCEPT all -- 192.168.1.0/24 0.0.0.0/0 n/a DENY all l- 192.168.1.0/24 0.0.0.0/0 n/a DENY all l- 192.168.1.0/24 0.0.0.0/0 n/a ACCEPT all -- 0.0.0.0/0208.33.90.85 n/a ACCEPT all -- 0.0.0.0/0208.33.90.255 n/a DENY all l- 0.0.0.0/00.0.0.0/0 n/a then it seems to be the final (default) ruleset that's doing the logging. but where's this request coming FROM? from what i gather, the 172.*.*.* is a private net block, and 224.*.*.* is a broadcast net block... my intranet has two macs and even a skanky ol' windo~1 box attached to the masquerading debian server. what's up with this? -- See, if you were allowed to keep the money, you wouldn't create jobs with it. You'd throw it in the bushes or something. But the government will spend it, thereby creating jobs. -- Dave Barry [EMAIL PROTECTED]***http://www.dontUthink.com/ volunteer to document your experience for next week's newbies -- http://www.eGroups.com/messages/newbieDoc
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 -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 to Windows NT ), 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
Re: Tracking down IP's
On Sun, Dec 31, 2000 at 06:20:50PM -0700, John Galt wrote: > You are forbidden from posting for the rest of the millenium. Since it's > 6pm MST on the eve of the millennium, this shouldn't be too hard :) Punishment accepted. See youse all next year! -- Bob Bernstein at Esmond, Rhode Island, USA
Re: Tracking down IP's
You are forbidden from posting for the rest of the millenium. Since it's 6pm MST on the eve of the millennium, this shouldn't be too hard :) On Sun, 31 Dec 2000, Bob Bernstein wrote: > *** Retraction *** > > On Sun, Dec 31, 2000 at 03:36:13PM -0500, Bob Bernstein wrote: > > > What I gather is that this could be a student at isi.edu, which is > > apparently part of the Univ. of California, > > File this message under: Big Dummy Posts We Wish We Never Made > > It's all brain-dead nonsense, based on me not recognizing the private ip > range, and doing the following: > > # dig -x 172.16.72.113 > > ; <<>> DiG 2.2 <<>> -x > ;; res options: init recurs defnam dnsrch > ;; got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56478 > ;; flags: qr aa rd ra; Ques: 1, Ans: 0, Auth: 1, Addit: 0 > ;; QUESTIONS: > ;; 113.72.16.172.in-addr.arpa, type = ANY, class = IN > > ;; AUTHORITY RECORDS: > 16.172.IN-ADDR.ARPA.575 SOA blackhole.isi.edu. bmanning.isi.edu. ( > 19971501; serial > 10800 ; refresh (3 hours) > 900 ; retry (15 mins) > 604800 ; expire (7 days) > 86400 ) ; minimum (1 day) > > ;; Total query time: 7 msec > ;; FROM: CX937045-A.lncln1.ri.home.com to SERVER: default -- 127.0.0.1 > ;; WHEN: Sun Dec 31 17:19:49 2000 > ;; MSG SIZE sent: 44 rcvd: 125 > > A blackhole is just that. Duh Bob. > > > -- Pardon me, but you have obviously mistaken me for someone who gives a damn. email [EMAIL PROTECTED]
Re: Tracking down IP's
On Sun, 31 Dec 2000 17:17:46 -0700, JD Kitch said: > > 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. You did this as root, right? Check netstat too, to determine if that port is still in use. -- Andrew
Re: Tracking down IP's
On Sun, Dec 31, 2000 at 04:18:30PM -0600, Richard Cobbe wrote: > JD Kitch <[EMAIL PROTECTED]> wrote: > > 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=0x 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=0x 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=0x 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=0x 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=0x 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=0x 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. > > (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.) Correct, the IP I blocked out was actually my own. > 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. > 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. 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? > 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, Not a problem, I'll take any information at this point. ;) TIA, jdk
Re: Tracking down IP's
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=0x 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=0x 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=0x 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=0x 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=0x 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=0x 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. (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
Re: Tracking down IP's
On Sun, Dec 31, 2000 at 03:36:13PM -0500, Bob Bernstein wrote: > On Sun, Dec 31, 2000 at 12:16:59PM -0700, JD Kitch wrote: > > > 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=0x T=127 > > (#43) > > I don't know what tool generated this log entry. This is a situation where a > good IDS such as snort would shed a lot of light. For example, grepping a > set of snort rules for that port yields: While I agree snort is a good tool, I fail to see why the poster blanked out the source address but left the dest address. Therefore all speculation about "where" this packet came from is a bit premature. > What I gather is that this could be a student at isi.edu, which is > apparently part of the Univ. of California, trying his or her hand at > configuring an NT box in some weird way. Who knows? Come ON people, 172.16.0.0/12 is part of RFC 1918 Private Network Addresses. Also, in this case it's the poster's IP address (must be using NAT somewhere along the way). My (worthless) guess: the provider just got a new HP Openview box and it's doing autodiscovery on the network. Cheers, -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Inc. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgp9cI6selcC2.pgp Description: PGP signature
Re: Tracking down IP's
*** Retraction *** On Sun, Dec 31, 2000 at 03:36:13PM -0500, Bob Bernstein wrote: > What I gather is that this could be a student at isi.edu, which is > apparently part of the Univ. of California, File this message under: Big Dummy Posts We Wish We Never Made It's all brain-dead nonsense, based on me not recognizing the private ip range, and doing the following: # dig -x 172.16.72.113 ; <<>> DiG 2.2 <<>> -x ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56478 ;; flags: qr aa rd ra; Ques: 1, Ans: 0, Auth: 1, Addit: 0 ;; QUESTIONS: ;; 113.72.16.172.in-addr.arpa, type = ANY, class = IN ;; AUTHORITY RECORDS: 16.172.IN-ADDR.ARPA.575 SOA blackhole.isi.edu. bmanning.isi.edu. ( 19971501; serial 10800 ; refresh (3 hours) 900 ; retry (15 mins) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ;; Total query time: 7 msec ;; FROM: CX937045-A.lncln1.ri.home.com to SERVER: default -- 127.0.0.1 ;; WHEN: Sun Dec 31 17:19:49 2000 ;; MSG SIZE sent: 44 rcvd: 125 A blackhole is just that. Duh Bob. -- Bob Bernstein at Esmond, Rhode Island, USA
Re: Tracking down IP's
on Sun, Dec 31, 2000 at 12:16:59PM -0700, 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? traceroute -- Karsten M. Self http://kmself.home.netcom.com/ Evangelist, Zelerate, Inc. http://www.zelerate.org What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/http://www.kuro5hin.org pgpIJ44cCgt4E.pgp Description: PGP signature
Re: Tracking down IP's
On Sun, Dec 31, 2000 at 12:16:59PM -0700, JD Kitch wrote: > 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=0x T=127 (#43) I don't know what tool generated this log entry. This is a situation where a good IDS such as snort would shed a lot of light. For example, grepping a set of snort rules for that port yields: misc-lib:alert udp any any -> $HOME_NET 161 (msg: "SNMP public access"; content:"public";) misc-lib:alert udp !$HOME_NET any -> $HOME_NET 161 (msg:"BUGTRAQ ID 1009 - Possible attempt at Bay/Nortel Nautica Marlin DoS); dsize:0;) netbios-lib:alert udp !$HOME_NET any -> $HOME_NET 161 (msg:"NETBIOS-SNMP-NT-UserList"; content:"|2b 06 10 40 14 d1 02 19|";) vision.conf:alert UDP $EXTERNAL any -> $INTERNAL 161 (msg: "IDS333/SNMP-NT-UserList"; content: "|2b 06 10 40 14 d1 02 19|";) Follow up by surfing to (see last line above) http://www.whitehats.com/IDS/333 and also that Bugtraq ID looks interesting. What I gather is that this could be a student at isi.edu, which is apparently part of the Univ. of California, trying his or her hand at configuring an NT box in some weird way. Who knows? I would send a very nice comment to someone there along with your data and see what comes of it. -- Bob Bernstein at Esmond, Rhode Island, USA
Re: Tracking down IP's
Lo, on Sunday, December 31, Pollywog did write: > > On Sun, 31 Dec 2000 13:55:26 -0600 (CST), Richard Cobbe said: > > > > > Did you change your IP address in the above report? IIRC, 172.16.*.* is > > a block of private addresses. Packets to this address should be dropped > > automatically by an upstream router. My guess, therefore, is that these > > transmissions are coming from somewhere else in your network---probably a > > misconfigured SNMP manager who thinks you're an agent. > > I would ask my ISP if it was coming from them or from their upstream > provider. I had some odd stuff appearing in my logs once, coming from > the same IP address, and it was in fact coming from my ISP's upstream > provider. Either way, it's still a private IP address range. NOBODY should let packets with one of these addresses, either as source or destination, cross a network boundary. If the ISP is getting this traffic from its upstrea provider, it should configure the router between it and the provider to drop all private address ranges, and let the provider know it's leaking private IPs. Richard
Re: Tracking down IP's
Lo, on Sunday, December 31, ktb did write: > On Sun, Dec 31, 2000 at 12:16:59PM -0700, JD Kitch wrote: > > 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=0x T=127 > > (#43) > nslookup 172.16.72.113 > shows - > can't find 172.16.72.113: Non-existent host/domain > > Can't help you any more than that. > kent Sorry, should have clarified this in my post, but 172.16.72.113 is the *destination* address---i.e., the IP address of the machine doing the logging. Doing lookups on this aren't going help (even if it weren't a private IP address.) The source address was blocked out by the original poster. Richard
Re: Tracking down IP's
On Sun, 31 Dec 2000 13:55:26 -0600 (CST), Richard Cobbe said: > > Did you change your IP address in the above report? IIRC, 172.16.*.* is > a block of private addresses. Packets to this address should be dropped > automatically by an upstream router. My guess, therefore, is that these > transmissions are coming from somewhere else in your network---probably a > misconfigured SNMP manager who thinks you're an agent. I would ask my ISP if it was coming from them or from their upstream provider. I had some odd stuff appearing in my logs once, coming from the same IP address, and it was in fact coming from my ISP's upstream provider. -- Andrew
Re: Tracking down IP's
On Sun, 31 Dec 2000 13:34:02 -0600, ktb said: > On Sun, Dec 31, 2000 at 12:16:59PM -0700, JD Kitch 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=0x 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=0x 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=0x 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=0x 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=0x 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=0x 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. > run $whois 172.16.72.113 IANA (IANA-BBLK-RESERVED) Internet Assigned Numbers Authority Information Sciences Institute University of Southern California 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292-6695 run $ cat /etc/services|more snmp161/udp # Simple Net Mgmt Proto Probably harmless.
Re: Tracking down IP's
On Sun, 31 Dec 2000 12:16:59 MST, JD Kitch writes: >Can anyone tell me what this person is looking for here, and how I >can find out where this is coming from? port 161 is snmp, so it looks like someone´s trying to get information about your machine (or something at your ISP or the like is misconfigured), proto 17 is UDP which fits snugly since snmp is udp-based. >Security Violations >=-=-=-=-=-=-=-=-=-= >Dec 31 11:06:47 tower kernel: Packet log: output REJECT eth0 PROTO=17 xx.xx.xx >x.xx:61662 172.16.72.113:161 L=106 S=0x00 I=7632 F=0x 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. look for the ip-adress with whois -h whois.[ripe|arin|apnic].net and complain to the ISP/organization responsible for it. hth, &rw -- / Ing. Robert Waldner | Network Engineer | T: +43 1 89933 F: x533 \ \ <[EMAIL PROTECTED]> |KPNQwest/AT | Diefenbachg. 35, A-1150 /
Re: Tracking down IP's
Lo, on Sunday, December 31, JD Kitch did write: > 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=0x 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=0x 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=0x 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=0x 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=0x 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=0x 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. Someone (xx.xx.xx.xx) is poking at your SNMP port. Use /etc/protocols to map from PROTO=17 to udp, and then /etc/services to map from 161/udp to SNMP. (For those who don't know, SNMP (Simple Network Management Protocol) is a protocol system originally intended for monitoring and administering networked devices remotely.) I'm having to guess, based on RFC 760, but I think the other fields are: * L: packet length * S: type of service -- see RFC 760 * I: identification #; aids in reassembling fragments * F: fragment offset, possibly with the IP flags thrown in? * T: time to live. * and I don't know what (#43) represents. (If someone knows better, I'd love to hear corrections.) These are most probably not relevant here. Did you change your IP address in the above report? IIRC, 172.16.*.* is a block of private addresses. Packets to this address should be dropped automatically by an upstream router. My guess, therefore, is that these transmissions are coming from somewhere else in your network---probably a misconfigured SNMP manager who thinks you're an agent. If it's *not* somewhere else in your network, then to try to find out where it's coming from, do an nslookup on the source IP (the address you've blocked out) to get its domain, then try doing a whois lookup on that domain to see who's responsible for it. (And bug your sysadmins to drop packets coming in from outside your network addressed to the private address ranges.) For example, try typing `whois gmx.net' to see the kind of information you should be able to get. HTH, Richard
Re: Tracking down IP's
whois 172.16.72.113 IANA (IANA-BBLK-RESERVED) Internet Assigned Numbers Authority Information Sciences Institute University of Southern California 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292-6695 Netname: IANA-BBLK-RESERVED Netblock: 172.16.0.0 - 172.31.0.0 from what I remember 61662 is the favoured port of some form of widnoise trojan Jeff ktb wrote: > > On Sun, Dec 31, 2000 at 12:16:59PM -0700, JD Kitch 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=0x 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=0x 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=0x 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=0x 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=0x 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=0x 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. > > > > You can do a search for the port at - > http://www.snort.org/Database/portsearch.asp > > nslookup 172.16.72.113 > shows - > can't find 172.16.72.113: Non-existent host/domain > > Can't help you any more than that. > kent > > -- > "In order to make an apple pie from scratch, > you must first create the universe." > - Carl Sagan > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking down IP's
On Sun, Dec 31, 2000 at 12:16:59PM -0700, JD Kitch 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=0x 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=0x 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=0x 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=0x 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=0x 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=0x 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. > You can do a search for the port at - http://www.snort.org/Database/portsearch.asp nslookup 172.16.72.113 shows - can't find 172.16.72.113: Non-existent host/domain Can't help you any more than that. kent -- "In order to make an apple pie from scratch, you must first create the universe." - Carl Sagan
Tracking down IP's
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=0x 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=0x 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=0x 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=0x 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=0x 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=0x 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. TIA, jdk
