Yotam Rubin <yotamat_private> writes: > The spoofed packets usually arrive immediately after some host performs > a standard probe. Which tool is generating this traffic? > BTW, I am indeed NAT'ed, but 192.168.0.1 does not exist on our network. Believe it or not, the tool is windows explorer. (Or actually, the standard Windows network device API) When windows explorer looks for other SMB machines (either with broadcast packets or by attempting direct connections), it will often send out packets from all its source IP addresses, without careful regard for which interface has which IP address. This means that if you have two ethernet cards in your machine, one with an address of 192.168.1.2 on your internal network and one with an address of 24.12.34.56 on the external network, explorer may end up sending out packets on the external network from the IP address 192.168.1.2. As far as I can tell, windows tries to use the correct IP address with the correct interface and only ends up using the "try all addresses" strategy when that fails. I think that this may be a necessary strategy in places with asymmetric routing. Window's behavior gets even more bizarre because even "down" interfaces (for example, a dialup adapter when the modem is disconnected, or a virtual adapter of the type that windows uses to do VPN while not logged into said VPN) are assigned IP addresses. This means that your windows box can broadcast using all sorts of bogus source IP addresses if you have a complicated configuration. The following snippet from your snort log is a classic example of behavior I've observed from windows 98 using just explorer (and I suppose the same holds for other win* machines): (lines abbreviated) May 2 03:18:54 linux snort: SMB Name Wildcard: 211.228.43.101:137 -> May 2 03:18:58 linux snort: SMB Name Wildcard: 169.254.111.94:137 -> May 2 03:18:58 linux snort: SMB Name Wildcard: 211.228.43.101:137 -> May 2 03:18:58 linux snort: SMB Name Wildcard: 192.168.0.1:137 -> May 2 03:19:00 linux snort: SMB Name Wildcard: 211.228.43.101:137 -> May 2 03:19:00 linux snort: SMB Name Wildcard: 192.168.0.1:137 -> May 2 03:19:00 linux snort: SMB Name Wildcard: 169.254.111.94:137 -> May 2 03:19:01 linux snort: SMB Name Wildcard: 169.254.111.94:137 -> May 2 03:19:01 linux snort: SMB Name Wildcard: 211.228.43.101:137 -> May 2 03:19:01 linux snort: SMB Name Wildcard: 192.168.0.1:137 -> So what we have here is a SMB name wildcard from a "legitimate" IP address (211.228.43.101), followed a few seconds later by three bursts of packets from all three of the IP addresses 192.168.0.1, 211.228.43.101, and 169.254.111.94. Note that 192.168.0.1 is a common address one might expect to assign the "main" machine on one's own home network, and that 169.254.111.94 is in the 169.254.0.0/16 netblock that dhcp-enabled devices are supposed to use in the absence of other information. I believe that when a VPN or dialup interface is down, windows assigns it an IP in this range. So what you have here most likely is simply a windows box with two ethernet cards (one assigned the address 192.168.0.1 and sitting on an internal network; one assigned the address 211.228.43.101 and sitting on the external network) and an inactive dialup or VPN adapter. The user of that windows box is then using no fancy tool to attempt to find open shares on your machine. My answer for "what tool" is then "any tool that accesses network shares through the standard OS-provided network share API"; one such tool is windows explorer, but it's not exactly useful for scanning. (Though maybe there's some way to script it with active scripting stuff) Now the question I have for the list is this - does sharesniffer (www.sharesniffer.com) just use the standard windows networking calls to see if a particular machine has open shares, or does it make its own UDP packets? I'm guessing that it's the former, for a few reasons: 1) It may well be easier to code. 2) Their website says that you must have "Client for Microsoft Networks" installed in order to scan for shares. 3) It would explain the observed pattern of having seen plenty of SMB Name Wildcard requests in the past but only recently seeing these bogus addresses if the scanners switched from a tool that generated its own packets (with which you'd only see "legitimate source" packets) to a tool that used the OS's networking calls (with which you'd see the bogus-source packets, assuming that the machine was configured with multiple adapters) --- ObDisclaimer: Above, the usage of the terms "Windows", "windows 98", "active scripting" and "win*" all refer to the Microsoft products bearing those and similar names. Most of those names are trademarks of Microsoft Corp. "ShareSniffer" appears to be a trademark of ShareSniffer, Inc. In any case, no trademark mentioned deliberately or accidentally above belongs to anyone except the respective trademark holder. (Well, duh)
This archive was generated by hypermail 2b30 : Fri May 04 2001 - 08:40:50 PDT