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. -- Ronny Aasen <[EMAIL PROTECTED]> ------------------------------------------------------- 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
