Comments at end.
At 07:09 AM 6/30/2004 -0400, Sean Covel wrote:
Norton is a great tool, but it doesn't pickup spyware. There has been a LOT of spyware/virus mixing lately. Try Spybot Search and Destroy. We once had a single machine with some spyware app running flooding the firewall trying to "call home." Killed the spyware, traffic stopped.
Brad Klinghagen wrote:This isn't the full format of the log file. I sent the full file to Tom Eastep to look at. As for virus, doubtful, since the computer is running the latest version of Symantec Anti-Virus 2004 and get updates whenever available (initiates the updates). I've set up the firewall rules so that if a computer on the LAN side initiates a request, then the response is allowed in; so if this were a response, it would be allowed in. But since I have latest virus stuff, viruses should be wiped out quickly - and my wife practices "safe Internet." I should also note, the computer is a Win2k workstation, and I have shut down the web server so there is no port 80 or 443 service port open on it and the firewall rules do not allow DNAT to this computer. Right now the only DNAT rules are for a VoIP phone from Vonage and Linux Web Server which happens to be shut down for right now. I believe I encountered the IIS issue Saturday night when I set up another firewall for someone. They had a couple thousand entries over a two hour period that looked suspicious. That's what prompted me to ask this question. Thank you for the thoughts though. bpk On Tue, 2004-06-29 at 23:42, Ronny Aasen wrote:
On Wed, 2004-06-30 at 01:16, Brad Klinghagen wrote:
I just wanted to check to make sure I'm looking at the Shorewall logs correctly. Below, I've pasted a small sample of what I'm seeing in my log file. The particular IP address that begins with 66 is the source and 10.1.1.65 is the destination. Obviously the 10 IP address is within my LAN. The second to last column shows the destination port number that is trying to be used. This is only a small portion of the list, there are hundreds of listings, and the destination port number keeps changing, while the source port number stays at 80, and this source IP is always trying to get to the same destination.
I am DROPing these packets and logging them because they are unwanted traffic. When I trace the public IP, there is no site there. In similar cases, sometimes there is a Microsoft IIS server there under construction. I did a 'dig -x 66.232.154.8,' and I got no answer as far as the owner of the IP address. Sometimes when I execute the 'dig -x' instruction, there will be some information, but usually the IP address is a client IP of an ISP (like Verizon, or Comcast).
Is it right to assume that this traffic is a hacker using automated software trying to probe for weaknesses in my firewall or computer setup? Or is it something else completely, something much less sinister? Could this be some ad software, or something like it? If this isn't someone trying to get in, how can you tell in your log files. I've got a number of various entries of unwanted IP attempts to access my network; some I believe is just spurious traffic, but others look like concerted effort to get at my computers.
The issue with this sample is I don't know how this person, or software is using the internal IP address of 10.1.1.65 because I'm using NAT (I suppose they stripped off the TCP/IP header, does that not suggest maliciousness?). Also, that IP address corresponds to the only Win2k computer in my whole network, and there is no other access attempts to any other internal computer.
eth0 eth1 66.232.154.8 10.1.1.65 TCP 80 1986 Jun 26 07:28:43 eth0 eth1 66.232.154.8 10.1.1.65 TCP 80 1986 Jun 26 07:28:49 eth0 eth1 66.232.154.8 10.1.1.65 TCP 80 1986 Jun 26 07:28:49 eth0 eth1 66.232.154.8 10.1.1.65 TCP 80 1986 Jun 26 07:29:01 eth0 eth1 66.232.154.8 10.1.1.65 TCP 80 1986 Jun 26 07:29:26 eth0 eth1 66.232.154.8 10.1.1.65 TCP 80 1986 Jun 26 07:30:14 eth0 eth1 66.232.154.8 10.1.1.65 TCP 80 1986 Jun 26 07:30:44 eth0 eth1 66.232.154.8 10.1.1.65 TCP 80 2039 Jun 26 07:30:47 eth0 eth1 66.232.154.8 10.1.1.65 TCP 80 2039 Jun 26 07:30:48 eth0 eth1 66.232.154.8 10.1.1.65 TCP 80 2039 Jun 26 07:30:53
eth0 eth1 66.232.154.8 10.1.1.65 TCP 80 2039 Jun 26 07:30:54 eth0 eth1 66.232.154.8 10.1.1.65 TCP 80 2039 Jun 26 07:31:06 eth0 eth1 66.232.154.8 10.1.1.65 TCP 80 2039 Jun 26 07:31:30 eth0 eth1 66.232.154.8 10.1.1.65 TCP 80 2039 Jun 26 07:32:18 eth0 eth1 66.232.154.8 10.1.1.65 TCP 80 2039
does your log realy look like that ? always port the orginal since it's from port 80 i'd have 2 wild guesses 1. your w2k box has a virus, that do httpd requests and you see the responses beeing blocked in the firewall. 2 the remote iis is infected by one of the iss exploit viruses making it spew out packages seen a few of those lately. but that it would find your 1 w2k box must be a huge coincidence
if you change the ip of the w2k and the packages dop in your log followes to the new ip, then i'd take the w2k off the net for a forencis.
One thing the discussion seems to have missed up to now is the character of the source host. Although it doesn't have a reverse-DNS entry, as you noted, it is easy to ping and traceroute to. The penultimate entry in the traceroute (from here) may tell you something informative about it:
15 pos6-0.tpa.neutelligent.com (64.156.25.114) 128.832 ms 128.095 ms 127.927 ms
16 66.232.154.8 (66.232.154.8) 126.038 ms 126.491 ms 127.674 ms
(BTW, it is fairly commonplace for hosts to lack reverse-DNS entries. The people who are authoritative for IP number ranges -- usually but not always ISPs -- are less than rigorous about maintaining reverse-lookup DNS databases.)
Also, if you go to the ARIN Website (http://www.arin.net/whois/index.html), you can determine that this address is part of a block assigned to:
OrgName: Hostway Corporation
OrgID: HSWY
Address: 1 N. State St.
City: Chicago
StateProv: IL
PostalCode: 60602
Country: US(The database includes more info than this; go to ARIN if you want to see it. Or you can get it on a Linux host with "whois -h whois.arin.net 66.232.154.8".)
Finally, if you connect to its Web site with a browser, you'll see the default home page that gets installed with an unconfigured Apache install. I don't know what this might mean, but it does suggest that the offsite end is not running IIS.
As to the traffic itself ... unless the offsite end is on the same ISP as you (something you have not told us anything about), it is hard to imagine any way that traffic is getting to your NAT'd Win2K host except as reply traffic. Your ISP would not route traffic from off its "LAN" to a private address, so the arriving packets must be addressed to your router's external interface. The full log entries, which you've not posted even a sample of, could help you verify this guess. (Tom's latest response, which I just saw, supports this guess.)
So I surmise that the log entries you posted in abridged form are being made by a rule that looks at the traffic *after* the NAT (de-MASQ) step has been applied. It would be easier to get some understanding of what this traffic is if you told us why your ruleset DENYs it (if it is a stock rule, which one; if it is a custom rule you added, where did you add it?).
Bottom line: you need to pay more attention to the suggestion, which several others have already made, that the traffic results from something residing on your Win2K machine. Whether it be a virus, adware, spyware, some "feature" of IE, or something else ... even its user doing something behind your back ... is just an exercise in getting the name right. If you can't delouse the Win2K machine directly, I suggest you sniff all traffic coming from it to the LEAF router and see what it is generating ... or at least add a rule that will log all outgoing traffic to 66.232.154.8 .
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
