Jeff Newmiller wrote: > > On Fri, 8 Mar 2002, Michael D. Schleif wrote: > > > Jeff Newmiller wrote: > > > > > > On Fri, 8 Mar 2002, Michael D. Schleif wrote: > > > > > > > We are seeing martians on internal networks on a regular basis. > > > > > > > > Usually, it is traceable to users logging into AOL over our high speed > > > > internet connections: > > > > > > > > 172.128.0.0 - 172.191.255.255 > > > > > > > > Today, we saw one from United Airlines: > > > > > > > > 205.174.16.0 - 205.174.23.255 > > > > > > > > [1] How does this happen? > > > > > > I often wonder how it happens that people who should know better fail to > > > provide specific error and log messages and explain what they know about > > > the particulars of the ip addresses, routes, machines and connections > > > involved. It is hard to trust reports as sanitized as this. > > > > Jeff, I respect your intelligence and firewall skills; however, if you > > read exactly what I posted, then you will know exactly what there is to > > know. > > Troubleshooting is like a tree... if you only describe the trunk and one > branch, we cannot be expected to describe the right twig for you to look > at.
I did not see your reply until after my reply to Matt. Again, allow me to apologize to everyone for my abrasiveness. Is it possible to ask a generic question on this list? I was trying to ask generic questions, answers to which can lead me to understand the extent of these issues and the direction to take in fixing the problems -- if, indeed, these issues are truly problems and require fixing. If I ``should know better'', then I am truly the dummy here, because I truly did not know what information to include -- hence, my closing ``What do you think?'' I do not see this as a firewall setup/configuration issue; but, I am willing to consider any compelling arguments. > > > On the surface, the idea that packets should be generated within your LAN > > > with source addresses outside your network would suggest something is > > > seriously broken (accidentally or purposefully) with the workstation > > > generating the packets. Yes. And, what information that will lead to resolving this issue remains unspecified. > > > > [2] Why does this happen? > > > > > > Speculation: if your AOL users are actually dialling into AOL while being > > > on the network, they may be temporarily acquiring an IP from AOL, and > > > Windows could possibly screw up and ships packets out the wrong interface. > > > However, something would have to be pretty weird with the AOL software if > > > it decided it had an AOL IP even if no dialup had occurred. There could > > > possibly be overlap when a dialup connection was lost as well. > > > > Please, please, please, read my post and respond accordingly: > > > > `` ... users logging into AOL over our high speed internet connections > > ... '' > > I read that. See below. > > > Or, even if they were, the questions remain the same -- what's the > > difference? > > Each interface is supposed to have an ip address. If the wrong IP address > is appearing on an outbound packet, the first possibility that presents > itself to my mind is that a port bound on one interface is somehow sending > packets out on another interface. > > The second interface may not be a dialup interface... but it is an obvious > one that you did not explicitly rule out in your first post. I thought that I had -- what phrase ought I to use, instead of ``high speed internet connection'', to convey this information? > If some > tunnelling is going on, then virtual interfaces could be > involved. However, Occam's Razor suggests that the simplest solution is > the most likely one. Since I am not aware of tunnelling in the described > software, and dialups are very common with that software, I speculated. Yes, speculation can be powerful. I do not object to speculation. I did, however, bristle at ``people who should know better fail'' -- I did not, and still do not, know what information is required to resolve these issues. > > > > [3] Is this exploitable? > > > > > > Insufficient data. > > > > How much data will suffice? > > > > A smattering of log entries: > > > > Feb 26 08:17:36 redtrout kernel: martian source 0b49a2ac for ffffffff, > > dev eth1 > > Feb 26 08:21:11 redtrout kernel: martian source 490b99ac for ffffffff, > > dev eth1 > > [...] > > While you may feel like you are conveying some message about the > unreasonableness of my request, you are actually spewing on a public > mailing list. A few samples, with a summary of the interfaces involved, > and the routing table for one of these "AOL" computers would be much more > effective. Please, make such a suggestion earlier in your responses. I do not know about others; but, if I'm a dummy and do not know the proper way to present the problem, a simple suggestion like this -- upfront -- goes a long way toward effective communications. Again, it is difficult for me to know how much data to provide and at what point -- either I submit inadequate data or it is excessive. That is why, as a general rule, I search the archives first and, if that search proves fruitless, I post as briefly as possible to the list, hoping that somebody will suggest *what* is required for them to analyze the problem. Look at that data. There is an awful lot going on and many different networks involved on both sides of the destination/source equation. Apparently, you see this as an attempt to waste bandwidth; but, I did filter out alot of entries that I feel are not appropriate to this thread. We do see martians in other contexts and I did not include those entries explicable by other means. We have not yet been able to fully investigate the United Airlines connection on pinktrout that occured yesterday. That one example appears similar to, but obviously different from all of the others, which are clearly related to aol connections. > > For those who cannot be bothered to find their hex calculators: Again, an unfortunate choice of words . . . > > 0.0.234.239 efea0000 > > 12.248.73.21 1549f80c > > 24.147.110.151 976e9318 > [...] > > 172.128.190.181 b5be80ac > > 172.129.46.164 a42e81ac > > [...] > > > What more do you need? > > On an offending workstation, > > ipconfig > netstat -rn > netstat -a > > I am not as familiar with networking on Windows as I am on Linux, but I > have some reference books and the problem here is not on the firewall. > On Linux I would use lsof also, but I don't know what the equivalent would > be under Windows. MSINFO.EXE? The offending workstations are all windoze boxen, mostly win98, which really limits data that can be collected. All workstations get *all* of their network configuration via dhcp and none of the offenders receives any special configuration, relative to its peers. There are several (4 or 5) offending workstations that we know about. c:\Program Files\Common Files\Microsoft Shared\MSINFO\msinfo32.exe from one of my network's win98 box (not and offender) generates a 270kb file. Unfortunately, we do not have ready access to the offending boxen; but, we will get this information next week. It maybe interesting to know that aol installs a special ``adapter'' that is purported to behave similarly to an hardware nic. In fact, on win9x, at least, it is next to the nic in network neighborhood properties and is near identically configured. Thank you, Jeff, for looking beyond my abrasiveness and offering constructive suggestions. -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
