72.14.207.104

I'm getting a lot of (unsolicited?) traffic from this address, while my
own IP address changes due to DHCP IP address change obscurity. It is on
multiple high ports. There is no reverse DNS showing. It all looks like
tcp traffic. So far as I know it is all bouncing off my firewall, and
could be ignored. There's no indication of intrusion or unexpected
outbound network traffic.

I'll institute additional egress logging rules to log and re-validate my
belief that this is not requested traffic. And I'll capture and
examine some of this traffic.

Before I do, I would ask for any information about this address or
unsolicited traffic from it. Since it has been pounding on my boxen at
various IP addresses, I have taken a look at it and have found very little
info.

Appreciation.

This is the kind of thing I am seeing now (or a few minutes ago.) It's
all inbound traffic.

Mon Jun 13 23:15:44 EDT 2005

# grep -c "72.14.207.104" /var/log/messages*

/var/log/messages:57
/var/log/messages.1:30
/var/log/messages.2:0
/var/log/messages.3:0
/var/log/messages.4:0

Tue Jun 14 03:38:17 EDT 2005

# grep -c "72.14.207.104" /var/log/messages*

/var/log/messages:150
/var/log/messages.1:30 /var/log/messages.2:0 /var/log/messages.3:0
/var/log/messages.4:0

On Mon, 13 Jun 2005 22:31:11 -1000, Angela Kahealani wrote:

> Newsbox wrote:
>
>> I'm getting a lot of (unsolicited?) traffic from this address, while
>> my
>> own IP address changes due to DHCP IP address change obscurity. It is
>> on
>> multiple high ports. There is no reverse DNS showing. It all looks
>> like
>> tcp traffic. So far as I know it is all bouncing off my firewall, and
>> could be ignored. There's no indication of intrusion or unexpected
>> outbound network traffic.
>>
>
> Google.Com owns the address...
>
> $ man man
> $ man whois

Thanks! I'm onto it. Though I might take a few hours off before the heavy
work. Blessed, restful sleep comes in it's own time :)

Appreciation.

On Mon, 13 Jun 2005 22:31:11 -1000, Angela Kahealani wrote:

> Newsbox wrote:
>
[...]
>
> Google.Com owns the address...
>
> $ man man
> $ man whois

You are right and I checked it. You are correct that whois proved more
informative than reverse DNS lookup, and the address in question is owned
by google. What I found next might be of general interest.

It appears that where I am, DNS for google.com resolves to 216.239.39.99,
both from my ISP's DNS servers and from GOOGLE's (and consistently). So
when my browser sends a get to 216.239.39.99, and the firewall sees an ACK
from 72.14.207.104, perhaps the firewall is doing exactly what it is
supposed to do by LOGging and DROPping that ACK packet. When I put
"216.239.39.99" into the location bar everything works beautifully. But
when I put in "google.com" it times out, and I get hits from 72.14.207.104.

As an additional factor, I'm still receiving unsolicited traffic from
72.14.207.104 at random times even when I am not attempting to connect to
google.

I'll look into this some more, and very much appreciate your quick (<15
minutes) and knowledgeable help. I think I'm beginning to feel better
now. Thanks again.

> It appears that where I am, DNS for google.com resolves to 216.239.39.99,
> both from my ISP's DNS servers and from GOOGLE's (and consistently). So
> when my browser sends a get to 216.239.39.99, and the firewall sees an ACK
> from 72.14.207.104, perhaps the firewall is doing exactly what it is
> supposed to do by LOGging and DROPping that ACK packet. When I put
> "216.239.39.99" into the location bar everything works beautifully. But
> when I put in "google.com" it times out, and I get hits from 72.14.207.104.
>
> As an additional factor, I'm still receiving unsolicited traffic from
> 72.14.207.104 at random times even when I am not attempting to connect to
> google.
>
> I'll look into this some more, and very much appreciate your quick (<15
> minutes) and knowledgeable help. I think I'm beginning to feel better
> now. Thanks again.

I'd appreciate it if you'd look into this some more and tell us your
findings.

I also frequently get unsolicited traffic, i.e. connect attempts, from a
few locations that pass through my NAT router and then are dropped and
logged by my firewall (Firestarter running under Xandros). This can
happen a long time (e.g. 30 min or more) after I last connected to the
address in question with my browser (Firefox), if I connected to it at
all in that session. When I posted this puzzle in this newsgroup, I
received the following response from Rincewind:

"The above are responses from a web server (SPT=80). You sometimes get this
behaviour when the web server is so slow to respond that the connection is
timed out by your browsing machine, but the router still remembers the
connection and passes it through. I see this frequently with one of the
news servers I use."

And another person responded:

"Those appear to be http servers that are responding to a SYN request
from your machine. If you accessed these sites from a browser but then
closed the browser before the response came back you would get this sort
of thing happening.
...... A connect attempt would be a SYN packet. These appear to be
acknowlegments of SYN packets sent by your machine."

Perhaps you're dealing with something similar. I know rather little
about the TCP/IP protocol and don't really understand what is going on.
I was mostly concerned about the fact that inward-bound packets were
able to pass through my NAT router that ostensibly were not a response
to a connection that I had initiated.

Once you've figured this out, could you explain it in novice's terms?
Thanks.

Robert

On Fri, 17 Jun 2005 15:15:01 -0400, Robert Glueck wrote:

>> As an additional factor, I'm still receiving unsolicited traffic from
>> 72.14.207.104 at random times even when I am not attempting to connect
>> to google.
>>
>> I'll look into this some more, and very much appreciate your quick (<15
>> minutes) and knowledgeable help. I think I'm beginning to feel better
>> now. Thanks again.
>
> I'd appreciate it if you'd look into this some more and tell us your
> findings.

Hi Robert,

I'm just a normal user with a strong interest in security. I certainly
have been looking into it and have more looking to do before I will be
satisfied (that I know enough to feel secure in reconnecting that box.)
I'll be glad to share with you what I find right here, where other more
knowledgeable readers can comment and correct, if I err. For starters,
every bit of advice that was posted here was good and correct (and fast
and helpful), as far as I can determine and believe. And I appreciate all
of it. What I have found or will find might not be precisely analogous to
what you have seen or are seeing, but will try to keep my responses
relevant. Also, this may take some time before I fully understand it
myself, if ever.

> I also frequently get unsolicited traffic, i.e. connect attempts, from a
> few locations that pass through my NAT router and then are dropped and
> logged by my firewall (Firestarter running under Xandros). This can
> happen a long time (e.g. 30 min or more) after I last connected to the
> address in question with my browser (Firefox), if I connected to it at
> all in that session. When I posted this puzzle in this newsgroup, I
> received the following response from Rincewind:
>
> "The above are responses from a web server (SPT=80). You sometimes get
> this behaviour when the web server is so slow to respond that the
> connection is timed out by your browsing machine, but the router still
> remembers the connection and passes it through. I see this frequently
> with one of the news servers I use."
>
> And another person responded:
>
> "Those appear to be http servers that are responding to a SYN request
> from your machine. If you accessed these sites from a browser but then
> closed the browser before the response came back you would get this sort
> of thing happening.
> ...... A connect attempt would be a SYN packet. These appear to be
> acknowlegments of SYN packets sent by your machine."
>
> Perhaps you're dealing with something similar. I know rather little
> about the TCP/IP protocol and don't really understand what is going on.
> I was mostly concerned about the fact that inward-bound packets were
> able to pass through my NAT router that ostensibly were not a response
> to a connection that I had initiated.
>
> Once you've figured this out, could you explain it in novice's terms?
> Thanks.
>
> Robert

I don't know anything about your NAT router, so can't comment on that.
While not saying your should ignore that issue, an iptables firewall by
itself _should_ be quite adequate for any need. Bearing in mind that
defense in layers is a superior strategy, in the event of an unknown or
undetected failure, a second layer could still protect.

I would say I have at best an intermediate level capability with iptables.
I feel as if I can read and write and understand iptables commands, and
can effectively use them for my custom purposes. I have been able to
repair the apparent firewall issue on the box with the problem, but don't
necessarily understand why any repair was necessary. The fw was running
and tested for many months with no problem, and nothing I am aware of
doing (I'm usually pretty careful and leave lots of records and tracks for
myself to check back on) _should_ have caused the kind of issues I was
seeing.

If you are on DHCP (dynamic IP address), firestarter has a big advantage
in simplicity and ease of use because it deals well with dynamic IP
address assignments. If you have static addresses you might want to look
at firehol. You can find it on google if your google doesn't quit like
mine did. These are both "front-ends" to iptables. To deal directly with
iptables, there are good tutorials, suggestions and sample scripts
available (besides man iptables!), some posted here in the past. Others
are good in many ways, but if you hit Rusty's pages you will see how good
he is at making it clear and easy to understand.

The inherent problem with front-ends is not convenience, usability or
effectiveness, but rather that they jump several levels and make the
process opaque ("easy") to the user. ie.: firestarter is a script for a
GUI that includes a "Wizard" interface to gather your preferences and
needs (very nice). The "Wizard" writes a configuration script file (very
clever and abstruse) which is called from another script file when you
click the "start firewall" button or start your connection or computer,
whichever. The actual iptables commands are generated dynamically and not
directly saved. You can view your rules but not the commands that wrote
them. Unless your head is four feet wide, you might have trouble seeing
through all those layers to find out what went wrong. That's where I am
now. It might not be your issue.

Agreed, the "TCP/IP" stuff isn't immediately obvious and easy to
understand without at least a lot of reading. But you can watch it work
in real time and study at at your leisure with (probably) ethereal. But
be careful because ethereal deals with many protocols and so has frequent
security upgrades. Be especially careful to be current with your
installed ethereal version. You can also look at your logs to see what
has been stopped and why. That's more than I can talk about now.

Now about those pesky unsolicited packets:
The advice you cited is good advice. Unsolicited traffic has many
reasons, almost all not good. It will probably be with us a long time.
As I remarked earlier, whois may be better in some cases than nslookup,
host or dig. YMMV. OTOH, a reverse DNS lookup (host, etc) may be needed
before you can get a whois answer. Some addresses seem to have no public
records at all. It's all very dodgy at times. If someone is poking
unwanted traffic at you, the first thing you want to know is who it is,
then what it is. Failing those, you want to protect yourself.

As long as your firewall is knocking them all down, you have nothing to
worry about. But how do you know that they are all being knocked down?
.... A much more difficult question to answer.

When you get unsolicited traffic more than 30 minutes after you have
terminated a connection (as you and I have), something is wrong. Traffic
can go around the world several times in a handful of seconds, at worst.
Connections normally time out in a matter of a handful of minutes at most.
The #1 probable cause is something is banged up on either your (my)
system, the responding system, or some system in between. That could be
you, me or some intermediary losing grip on security.

Then there's the other thought: that someone got between you and your
correspondent. ... Hacked systems or routers, "man-in-the-middle" are all
possibilities. I'm not equipped to talk with authority.

I have some research and thoughts about this incident and will share
whatever I can tell you. I'm not done and will need more time to know
details, if ever. I may yet just dump that box and reuse the hardware
with different software. It was a good box, but if you cannot trust it,
what good is it? If my worst paranoid suspicions were true, I wouldn't
want to post them on a NG without first validating to those who could
possibly correct the issues.

Give me some more time, and ask some more question. I'll answer as best I
can, and wish you best wishes.

On Fri, 17 Jun 2005 15:15:01 -0400, Robert Glueck wrote:

[...]

> Once you've figured this out, could you explain it in novice's terms?
> Thanks.
>
> Robert

I haven't figured out out yet, and I'm ignoring some issues that do not
seem unique to the affected system. Now I need some help if someone is
able to provide it.

It seems clear to me that something or some things were broken on that
system when "bad characters" were set free on low-level software on the
system. I have googled all combinations without finding what I think I
need to know.

Referencing man iptables, look at "TARGET EXTENSIONS" and below that "LOG"
and then "--log-prefix _prefix_". There is no detail on acceptable or
valid characters or how they may or may not be used. I've used this
before without issue, but it seems clear to me now that this is how the
breakage occurred.

My Bugzilla account for Netfilter/iptables is on the affected system,
which I am trying to keep disconnected as much as possible. Can someone
please point me to a ruleset? If not, I'll try to find a way to get to
Bugzilla.

I'll also need to know some more about repairing/replacing
bonobo-activation-server before I can know if that system is repairable.

Thanks.

On Fri, 17 Jun 2005 15:15:01 -0400, Robert Glueck wrote:

[...]

> I'd appreciate it if you'd look into this some more and tell us your
> findings.

[...]

> Perhaps you're dealing with something similar. I know rather little
> about the TCP/IP protocol and don't really understand what is going on.
> I was mostly concerned about the fact that inward-bound packets were
> able to pass through my NAT router that ostensibly were not a response
> to a connection that I had initiated.
>
> Once you've figured this out, could you explain it in novice's terms?
> Thanks.
>
> Robert

Lawrence Baldwin wrote a pretty nice page about this in mostly
non-technical terms, here:

http://www.mynetwatchman.com/kb/res-falsepos.htm

Your NAT router likely has a longer timeout limit for a connection than
your computer, and you probably shouldn't worry too much about that so
long as your computer firewall is stopping unwanted traffic. There are
different opinions on having multiple firewalls and running a firewall at
all on a desktop workstation, but I see nothing wrong with what you are
doing. You may still see some of this traffic bouncing off your iptables
firewall. But if your computer has expired a connection and your router
has not, that is exactly what you should be seeing. You can look at the
output of "netstat -tupan" for some more specific data on your
connections. (man netstat)

Best wishes.

>
> It appears that where I am, DNS for google.com resolves to
216.239.39.99,
> both from my ISP's DNS servers and from GOOGLE's (and consistently).
So
> when my browser sends a get to 216.239.39.99, and the firewall sees
an ACK
> from 72.14.207.104, perhaps the firewall is doing exactly what it
is
> supposed to do by LOGging and DROPping that ACK packet. When I put
> "216.239.39.99" into the location bar everything works beautifully.
But
> when I put in "google.com" it times out, and I get hits from
72.14.207.104.
>

I too was having the exact same trouble.... pinging google.com from
the pc would reply with a 216.239.39.99 address but the browser would
time out when trying to find google.ca or google.com.
After many a sleepless night I found on my LEAF router (which runs
shorewall firewall) that it has a norfc1918 filtering option in it...
but default it would block all traffic from the IP address range of
72.0.0.0 /5 as this was a reserved range. Google must have
purchased a small block of these IPs recently (72.14.207.0) After I
removed that entry and restarted the firewall I was able to get to
google.com.
A quick search on the web reveals that these IPs have something to do
with a google web accelerator. Even though it isn't installed on my
PC, some how the browser(IE 6.0) still wants to goto the
72.14.207.104 IP, even though my DNS servers are showing the
216.239.39.99.

regards,
Brian

On Wed, 20 Jul 2005 15:39:45 +0000, bfisher wrote:

>>
>> It appears that where I am, DNS for google.com resolves to
> 216.239.39.99,
>> both from my ISP's DNS servers and from GOOGLE's (and consistently).
> So
>> when my browser sends a get to 216.239.39.99, and the firewall sees
> an ACK
>> from 72.14.207.104, perhaps the firewall is doing exactly what it
> is
>> supposed to do by LOGging and DROPping that ACK packet. When I put
>> "216.239.39.99" into the location bar everything works beautifully.
> But
>> when I put in "google.com" it times out, and I get hits from
> 72.14.207.104.
>>
>
> I too was having the exact same trouble.... pinging google.com from
> the pc would reply with a 216.239.39.99 address but the browser would
> time out when trying to find google.ca or google.com.
> After many a sleepless night I found on my LEAF router (which runs
> shorewall firewall) that it has a norfc1918 filtering option in it...
> but default it would block all traffic from the IP address range of
> 72.0.0.0 /5 as this was a reserved range. Google must have
> purchased a small block of these IPs recently (72.14.207.0) After I
> removed that entry and restarted the firewall I was able to get to
> google.com.
> A quick search on the web reveals that these IPs have something to do
> with a google web accelerator. Even though it isn't installed on my
> PC, some how the browser(IE 6.0) still wants to goto the
> 72.14.207.104 IP, even though my DNS servers are showing the
> 216.239.39.99.
>
> regards,
> Brian

Thanks for the input. Apparently, what you are seeing is not exactly what
I am seeing, and neither is necessarily the same as I was seeing on 6/14.
Note that we are not the only ones seeing "strangeness" on google. See
this:

http://isc.sans.org/diary.php?date=2005-07-19

and today's entry (which after today might be):

http://isc.sans.org/diary.php?date=2005-07-20

The various issues seem to be browser specific, and there is mention of
involvement of javascripts. From previous experiences, I believe there
may be many subtle (and maybe not-so-subtle) differences among different
platforms, browsers, and javascript implementations, especially when
compared to Microsoft and IE "standards".

I have captured raw traffic with ethereal and studied to for clues, but
unfortunately my understanding is limited. On 6/14 I was directed by DNS
to the 216.239.39.99 address, but did not connect to it. Today I connect
to that address and get some limited traffic that does not display a page,
and the browser times out. I'm only seeing this kind of strangeness on
google. I have ruled out local firewall/connection issues. It may indeed
have something to do with their "web accelerator" or possibly some other
javascript they are serving. However, it does somehow seem to be
completely confined to google.

If someone wanted to try to analyze javascript code pulled out of a
captured HTTP packet I could try another capture and post a packet or two.
On the other hand I have no reason to believe they are sending me
anything different that what they are sending anyone else. So probably
anyone interested could look for h/h-self.

"Google isn't talkin'"

Best wishes.

On Wed, 20 Jul 2005 15:39:45 +0000, bfisher wrote:

[...]

> I too was having the exact same trouble.... pinging google.com from
> the pc would reply with a 216.239.39.99 address but the browser would
> time out when trying to find google.ca or google.com.
> After many a sleepless night I found on my LEAF router (which runs
> shorewall firewall) that it has a norfc1918 filtering option in it...
> but default it would block all traffic from the IP address range of
> 72.0.0.0 /5 as this was a reserved range.

[...]

After I
removed that entry and restarted the firewall I was able to get to
google.com.

[...]

> regards,
> Brian

I looked this up and found this. Still unexplained in my book ...

Rekhter, et al Best Current Practice [Page 3]

RFC 1918 Address Allocation for Private Internets February 1996


3. Private Address Space

The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private internets:

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

Thanks again and best wishes.