Re[2]: Spoofed RFC1918 Network Source Addresses...

From: Security Consultant (listrecipient@hanis.net)
Date: 11/19/02

  • Next message: dataspy: "Re: Subseven 2.2 Server?" 
    Date: Mon, 18 Nov 2002 18:15:04 -0500
From: Security Consultant <listrecipient@hanis.net>
To: Russell Fulton <r.fulton@auckland.ac.nz>, incidents@securityfocus.com

    Hello All,

       To clarify my initial question (see quoted previous message below),
    I've attached some log snippets of what I'm seeing...everything is
    space delimited -- Here's some useful information:

    1) a.b.c.133 is a trusted host to the organization that is seeing this
    traffic, but only to the point that it could communicate for specific
    application traffic such as Database server queries.

    2) 10.0.0.0, 10.3.0.0, 10.3.70.0 are subnets that exist in the
    organization's network -- Actually, it's just 10.3.0.0 and 10.3.70.0,
    but since they are children of the broader 10.0.0.0, it's pertinent.

    3) All of the heading descriptors should be self-explanatory, the Tm
    fields are the start and stop times that it saw the first packet and
    the last recorded time in an interval that it saw the last matching
    packet. The device that did the logging consolidates things like
    this. Sorry.

    4) All of this traffic was seen within the internal network, not from
    outside the firewall. Just for clarification, the host: a.b.c.133
    exists outside the firewall and the 10.x.x.x network addresses exist
    inside the firewall. In different logs, I have seen traffic from
    10.0.0.0, 10.3.0.0, and 10.3.70.0 destined to a.b.c.133. What I am
    not able to discern is actually which came first. I would tend to
    think that possibly the spoofed 10.x.x.x packets were generated first
    and because of stateful inspection, the replies from an exernal host
    are allowed back in...the thing that really gets me is the fact that
    I'm only seeing traffic from trusted hosts, not from all over the
    internet, which given my theory (of return packets) does not make much
    sense.

    5) There are a lot of misconfigured things within my clients
    environment and mostly I can figure things out...but this has gotten
    me really baffled. I just wanted to see if anyone else has seen
    ANYTHING similar to this. Any help is greatly appreciated.

    "StartTm" "LastTm" "SourceIP" "SourcePort" "DestIP" "DestPort" "TotalBytes"
    "22:13:29" "22:23:25" "a.b.c.133" "0" "010.003.000.000" "0" "226"
    "22:23:50" "22:23:50" "a.b.c.133" "0" "010.000.000.000" "0" "80"
    "23:33:16" "23:33:16" "a.b.c.133" "0" "010.003.000.000" "0" "144"
    "23:18:45" "23:39:18" "a.b.c.133" "0" "010.003.070.000" "0" "120"
    "23:48:58" "23:48:58" "a.b.c.133" "0" "010.000.000.000" "0" "146"
    "01:09:34" "01:09:34" "a.b.c.133" "0" "000.000.000.000" "0" "56"
    "01:14:39" "01:14:39" "a.b.c.133" "0" "010.003.000.000" "0" "88"
    "01:50:36" "01:50:36" "a.b.c.133" "0" "010.003.000.000" "0" "80"
    "02:03:02" "02:03:02" "a.b.c.133" "0" "000.000.000.000" "0" "148"
    "02:44:06" "02:44:06" "a.b.c.133" "0" "000.000.000.000" "0" "148"
    "02:54:28" "02:54:28" "a.b.c.133" "0" "010.003.070.000" "0" "476"
    "02:28:54" "02:59:18" "a.b.c.133" "0" "010.000.000.000" "0" "296"
    "03:03:24" "03:03:24" "a.b.c.133" "0" "010.003.000.000" "0" "40"
    "03:24:22" "03:34:50" "a.b.c.133" "0" "000.000.000.000" "0" "1146"
    "03:34:37" "03:59:28" "a.b.c.133" "0" "010.003.000.000" "0" "168"
    "03:59:39" "03:59:39" "a.b.c.133" "0" "010.003.070.000" "0" "868"
    "04:00:03" "04:00:03" "a.b.c.133" "0" "010.000.000.000" "0" "88"
    "04:33:50" "04:33:50" "a.b.c.133" "0" "000.000.000.000" "0" "146"
    "04:54:54" "04:59:29" "a.b.c.133" "0" "010.003.000.000" "0" "226"
    "04:59:45" "05:23:46" "a.b.c.133" "0" "010.003.070.000" "0" "316"
    "05:18:39" "05:25:10" "a.b.c.133" "0" "000.000.000.000" "0" "376"
    "06:29:11" "06:52:56" "a.b.c.133" "0" "010.000.000.000" "0" "204"
    "06:59:23" "06:59:23" "a.b.c.133" "0" "010.003.000.000" "0" "56"
    "06:48:09" "06:59:22" "a.b.c.133" "0" "010.003.070.000" "0" "306"
    "06:43:36" "07:05:21" "a.b.c.133" "0" "000.000.000.000" "0" "176"
    "07:28:33" "07:28:33" "a.b.c.133" "0" "010.000.000.000" "0" "146"
    "07:43:09" "07:43:09" "a.b.c.133" "0" "000.000.000.000" "0" "56"
    "08:35:32" "08:45:32" "a.b.c.133" "0" "000.000.000.000" "0" "188"
    "08:39:06" "08:53:20" "a.b.c.133" "0" "010.003.000.000" "0" "226"
    "08:34:49" "09:09:44" "a.b.c.133" "0" "010.003.070.000" "0" "3196"
    "09:24:07" "09:24:07" "a.b.c.133" "0" "000.000.000.000" "0" "40"

    Sunday, November 17, 2002, 2:07:35 PM, you wrote:

    RF> On Sat, 2002-11-16 at 10:03, Security Consultant wrote:
    >> Hello All,
    >>
    >> I've been following the thread here regarding the IP Spoofs from
    >> 0.0.0.0 with interest as I'm seeing something similar, but not the
    >> same in one of my client environments. I see packets from a specific
    >> internet host that the client has associations with (which presumably
    >> means they are allowing certain specific traffic from that host to
    >> pass via the firewall to other certain hosts within the environment)
    >> that are directed to subnet addresses, such as 10.0.0.0 or 10.1.0.0 or
    >> 10.1.2.0. Lots of different combinations. I also see other traffic
    >> that is either spoofed traffic or some sort of return traffic to these
    >> spoofed addresses as they are sourced with 10.0.0.0 or 10.1.0.0 or
    >> 10.1.2.0 or something like that. It is possible that the firewall or
    >> NAT device is improperly configured and is adding state for these
    >> spoofed addresses which might be destined for the internet and thus
    >> the return packets are making it back. It just seems odd that the
    >> only external addresses appears to be hosts that are "trusted" by the
    >> organization. Has anyone seen anything like this recently. This has
    >> been happening for at least a week. Thanks in advance for any help.

    RF> Logs (sanitized if necessary) would be useful, it's difficult to figure
    RF> out what going on from written description.

    ----------------------------------------------------------------------------
    This list is provided by the SecurityFocus ARIS analyzer service.
    For more information on this free incident handling, management
    and tracking system please see: http://aris.securityfocus.com

    Relevant Pages

    • Re: SOHO firewall dropping incoming 443 connections - incorrect state
      ... I take it this sample snip of your logs is from a single session? ... client host connecting to the firewall was a single host. ... because of the nature of HTTPS requests it uses a different ephemeral ...
      (comp.security.firewalls)
    • Re: Reverse http traffic
      ... Linksys calls it a firewall feature, and it has logs - but not everyone ... >> mystery packets directed to the problem machine or to the router ... Check open ports on the suspect ...
      (Incidents)
    • Re: OT: Best Antivirus?
      ... of a host (some say behind a poorly configured firewall). ... Hence, if it doesn't return host unreachable and packets are magically disappearing then it's a damn good bet the host you're looking at is there, and is trying to hide. ... The sense of security comes from people thinking "I'm not going to get hacked because I've installed ZoneAlarm, and stealthed my ports like GRC suggests". ...
      (rec.autos.sport.f1)
    • Re: [fw-wiz] CERT vulnerability note VU# 539363
      ... > attacks either, with our without state, nor are routers... ... > firewall is doing its job- stopping packets when there's an attack- ... Although the second technique mentions the CRC host after the firewall ...
      (Firewall-Wizards)
    • Re: got kppp connection but cant browse the net
      ... The 'gateway' is the host you send packets to for forwarding. ... but see that your firewall is not messing things up. ...
      (comp.os.linux.x)