Relentless knocking on firewall

I'm getting relentless pounding of my firewall by an IP address
10.203.185.129 which is coming thru my Motorola 5100 cable modem and
bouncing off the firewall of my Belkin 5F7230-4 DSL/cable gateway router. I
get a message shown below. There are others, but the one is very
persistant. My ISP, Charter, has been no help, sending a cable installer
that just shrugs and leaves me with 64K-107K on a 384K/128K line. Is there
anything I can do? I've changed channels and SSID and turned off
broadcasting. This has to affect performance. Here's a copy of the log:
Firewall log:
Sat Aug 21 21:27:35 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:27:51 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:28:07 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:28:09 2004 1 Blocked by DoS protection 10.202.0.1
Sat Aug 21 21:28:09 2004 1 Blocked by DoS protection 10.202.0.1
Sat Aug 21 21:28:23 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:28:39 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:28:55 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:29:03 2004 1 Blocked by DoS protection 10.202.0.1
Sat Aug 21 21:29:06 2004 1 Blocked by DoS protection 10.202.0.1
Sat Aug 21 21:29:10 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:29:14 2004 1 Blocked by DoS protection 10.202.0.1
Sat Aug 21 21:29:26 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:29:29 2004 1 Blocked by DoS protection 10.202.0.1
Sat Aug 21 21:29:42 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:29:58 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:30:14 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:30:15 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:30:30 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:30:46 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:30:46 2004 1 Blocked by DoS protection 213.64.177.151
Sat Aug 21 21:31:02 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:31:18 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:31:28 2004 1 Blocked by DoS protection 68.155.78.77
Sat Aug 21 21:31:34 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:31:50 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:31:57 2004 1 Blocked by DoS protection 172.28.88.21
Sat Aug 21 21:31:57 2004 1 Blocked by DoS protection 10.202.0.1
Sat Aug 21 21:32:06 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:32:22 2004 1 Blocked by DoS protection 10.203.185.129
Sat Aug 21 21:32:29 2004 1 Blocked by DoS protection 211.243.105.140
Sat Aug 21 21:32:38 2004 1 Blocked by DoS protection 10.203.185.129
Any ideas would be appreciated. Thanks, Terry (MO Ozarks)

Search results for: 10.203.185.129

OrgName: Internet Assigned Numbers Authority
OrgID: IANA
Address: 4676 Admiralty Way, Suite 330
City: Marina del Rey
StateProv: CA
PostalCode: 90292-6695
Country: US

NetRange: 10.0.0.0 - 10.255.255.255
CIDR: 10.0.0.0/8
NetName: RESERVED-10
NetHandle: NET-10-0-0-0-1
Parent:
NetType: IANA Special Use
NameServer: BLACKHOLE-1.IANA.ORG
NameServer: BLACKHOLE-2.IANA.ORG
Comment: This block is reserved for special purposes.
Comment: Please see RFC 1918 for additional information.
Comment:
RegDate:
Updated: 2002-09-12

OrgAbuseHandle: IANA-IP-ARIN
OrgAbuseName: Internet Corporation for Assigned Names and Number
OrgAbusePhone: +1-310-301-5820
OrgAbuseEmail: (E-Mail Removed)

OrgTechHandle: IANA-IP-ARIN
OrgTechName: Internet Corporation for Assigned Names and Number
OrgTechPhone: +1-310-301-5820
OrgTechEmail: (E-Mail Removed)

# ARIN WHOIS database, last updated 2004-08-21 19:10
# Enter ? for additional hints on searching ARIN's WHOIS database.

"Jim Miller" <(E-Mail Removed)> wrote in news:ZY6dnTbhZ4f3kbXcRVn-
(E-Mail Removed):

> Search results for: 10.203.185.129
>
> OrgName: Internet Assigned Numbers Authority
> OrgID: IANA
> Address: 4676 Admiralty Way, Suite 330
> City: Marina del Rey
> StateProv: CA
> PostalCode: 90292-6695
> Country: US
>
> NetRange: 10.0.0.0 - 10.255.255.255
> CIDR: 10.0.0.0/8
> NetName: RESERVED-10
> NetHandle: NET-10-0-0-0-1
> Parent:
> NetType: IANA Special Use
> NameServer: BLACKHOLE-1.IANA.ORG
> NameServer: BLACKHOLE-2.IANA.ORG
> Comment: This block is reserved for special purposes.
> Comment: Please see RFC 1918 for additional information.
> Comment:
> RegDate:
> Updated: 2002-09-12
>
> OrgAbuseHandle: IANA-IP-ARIN
> OrgAbuseName: Internet Corporation for Assigned Names and Number
> OrgAbusePhone: +1-310-301-5820
> OrgAbuseEmail: (E-Mail Removed)
>
> OrgTechHandle: IANA-IP-ARIN
> OrgTechName: Internet Corporation for Assigned Names and Number
> OrgTechPhone: +1-310-301-5820
> OrgTechEmail: (E-Mail Removed)
>
> # ARIN WHOIS database, last updated 2004-08-21 19:10
> # Enter ? for additional hints on searching ARIN's WHOIS database.
>
>
>

http://whatis.techtarget.com/definit...214010,00.html

Duane

"Wiz-z-z" <(E-Mail Removed)> wrote:
>This has to affect performance.
[every few seconds:
> Sat Aug 21 21:27:35 2004 1 Blocked by DoS protection 10.203.185.129
> Sat Aug 21 21:27:51 2004 1 Blocked by DoS protection 10.203.185.129
> Sat Aug 21 21:28:07 2004 1 Blocked by DoS protection 10.203.185.129

I can't see that effecting performance, it's not very often in terms
of your broadband bandwidth.

10.*.*.* is non-routable, so it's probably coming from inside your
provider's network. Try a 'tracert 10.203.185.129' and post the
results.

"Wiz-z-z" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> I'm getting relentless pounding of my firewall by an IP address
> 10.203.185.129 which is coming thru my Motorola 5100 cable modem and
> bouncing off the firewall of my Belkin 5F7230-4 DSL/cable gateway router.
I
> get a message shown below. There are others, but the one is very
> persistant. My ISP, Charter, has been no help, sending a cable installer
> that just shrugs and leaves me with 64K-107K on a 384K/128K line. Is
there
> anything I can do? I've changed channels and SSID and turned off
> broadcasting. This has to affect performance. Here's a copy of the log:
>
> Firewall log:
> Sat Aug 21 21:27:35 2004 1 Blocked by DoS protection 10.203.185.129
> Sat Aug 21 21:27:51 2004 1 Blocked by DoS protection 10.203.185.129
[snip]
> Any ideas would be appreciated. Thanks, Terry (MO Ozarks)

Terry,

IP numbers that start with "10" are part of three ranges dedicated to
"Detached Network Operation" - in other words, they're intended to be used
in IP networks which do NOT touch the Internet.

That means that IP numbers starting with 10 are not allowed on the Internet,
and they must be translated to "real" IP numbers before they can be routed.
There are three ranges dedicated to "detached" operation: here's the list,
from RFC1918.

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)

You probably wonder why I'm throwing all this information at you, and here's
the reason: "10" addresses CAN'T COME FROM THE INTERNET! Every Internet
router routinely drops _ANY_ packet having a detached address.

In other words, it's from another modem on the cable, since cable operators
use "10" addresses for the modems. If you own the modem, check for firmware
upgrades: if your modem checks out, tell Charter they have a problem.

HTH. YMMV.

William
--
William Warren
(Filter noise from my address for direct replies.)

In article <mOVVc.208145$eM2.83135@attbi_s51>,
William Warren <(E-Mail Removed)> wrote:
:That means that IP numbers starting with 10 are not allowed on the Internet,

False.

:and they must be translated to "real" IP numbers before they can be routed.

Only partly true.


:You probably wonder why I'm throwing all this information at you, and here's
:the reason: "10" addresses CAN'T COME FROM THE INTERNET! Every Internet
:router routinely drops _ANY_ packet having a detached address.

Definitely false.


IP addresses in particular ranges are reserved for "private networks",
according to RFC ("Request For Comments") 1918. RFC's make
*recommendations* of technical standards, and if someone does not follow
those technical standards, all you can do is ask them politely to change;
and if they won't change, then all you can do is exile them from
"polite society" (get the major routers involved enough that they will
stop routing packets for that host or provider.) RFC's have no
legal or legislative authority or enforcement mechanisms beyond
those available when you see anyone acting boorishly -- politeness,
shaming, or ostracism.


RFC 1918 says that one "must not" allow -outgoing- packets in private
number ranges to escape to the public internet, but it (and the
follow ups to it) only say that one "should not" allow -incoming-
packets in those ranges to enter your private network.

Thus, a 10.* packet could have originated anywhere in the world that
chooses to disregard the "do not let them leak out" clause, and make it
over to you through a chain of providers who do not impliment the
"please do not let them leak in either" clause.

It is fairly common for the big ISPs (especially the cable companies)
to allow in nearly everything, as they claim that their network
performance would suffer too much if they implimented blocking
of those addresses at all of their gateways. Which might be true for
some models by some vendors, but would be false for other models by
other vendors whom impliment this kind of simple filtering in hardware.


The original poster mentioned Comcast. I am not in the US and especially
I have not done any business with Comcast, but my recollection from
previous Usenet reading is that Comcast itself uses 10.* IP addresses
internally for its own equipment. I further seem to recall that Comcast
is one of the cable companies that has a "no servers" policy and
that they attempt to enforce that policy by having their equipment
"scan" (attempt to open) some of the common server ports on all the
user machines. If my recollections are correct, then the packets could
represent Comcast itself checking to see whether you are running servers.

--
"There are three kinds of lies: lies, damn lies, and statistics."
-- not Twain, perhaps Disraeli, first quoted by Leonard Courtney

On 22 Aug 2004 16:54:59 GMT, (E-Mail Removed) (Walter
Roberson) wrote:


>The original poster mentioned Comcast. I am not in the US and especially
>I have not done any business with Comcast, but my recollection from
>previous Usenet reading is that Comcast itself uses 10.* IP addresses
>internally for its own equipment. I further seem to recall that Comcast
>is one of the cable companies that has a "no servers" policy and
>that they attempt to enforce that policy by having their equipment
>"scan" (attempt to open) some of the common server ports on all the
>user machines. If my recollections are correct, then the packets could
>represent Comcast itself checking to see whether you are running servers.

I'd think it is probably comcast doing sweeps to see if currently
assigned IP addresses are connected to its system. I see very
similar activity from my cable supplier (they use internet
routable IP addresses though). If the activity is looking for
"servers", then they probably would be trying port 80 where most
of their concerns would be.

<William P.N. Smith> wrote in message
news:(E-Mail Removed)...
> "Wiz-z-z" <(E-Mail Removed)> wrote:
> >This has to affect performance.
> [every few seconds:
> > Sat Aug 21 21:27:35 2004 1 Blocked by DoS protection 10.203.185.129
> > Sat Aug 21 21:27:51 2004 1 Blocked by DoS protection 10.203.185.129
> > Sat Aug 21 21:28:07 2004 1 Blocked by DoS protection 10.203.185.129
>
> I can't see that effecting performance, it's not very often in terms
> of your broadband bandwidth.
>
> 10.*.*.* is non-routable, so it's probably coming from inside your
> provider's network. Try a 'tracert 10.203.185.129' and post the
> results.
>

Here's the results of the tracecrt :

Tracing route to 10.203.185.129 over a maximum of 30 hops
1 1 ms <1 ms <1 ms 192.168.2.1
2 7 ms 7 ms 8 ms 10.203.185.129
Trace complete.

I assume that means it belongs to my ISP, Charter, like one of the other
posters said. As an old retired Network Admin (pre-cable and wireless), I
hate it when someone messes with my firewall.
Thanks a lot guys for all the replies. ...Terry (MO Ozarks)

[snip]
> Thus, a 10.* packet could have originated anywhere in the world that
> chooses to disregard the "do not let them leak out" clause, and make it
> over to you through a chain of providers who do not impliment the
> "please do not let them leak in either" clause.

I don't think that's a realistic scenario. The "chain of providers" would
have to have agreements, and router tables, in place to make it possible,
and I'd be very surprised if any ISP would expose their network to that kind
of unaccountable traffic and the risk it represents. Detached network
addresses aren't routable because there is no automated way to route them:
_EVERY_ ISP in your chain would have to set up their routers by hand, or
would have to be accepting router-table changes from non-authoritative
sources, and either way is an invitation to disaster.

> It is fairly common for the big ISPs (especially the cable companies)
> to allow in nearly everything, as they claim that their network
> performance would suffer too much if they implimented blocking
> of those addresses at all of their gateways. Which might be true for
> some models by some vendors, but would be false for other models by
> other vendors whom impliment this kind of simple filtering in hardware.

Major ISP's have to deal source-routing compromises every day, and their
network performance might suffer by doing /24 or /32 routing of "real" IP
numbers, but I don't think that any ISP, major or minor, would ever agree to
do extra work in order to let RFC1918 addresses into their network: it's
just a needless risk. And if it's an automatic table change, any ISP willing
to believe a non-authoritative source when changing routes is asking for
trouble, and they know it.

> The original poster mentioned Comcast. I am not in the US and especially
> I have not done any business with Comcast, but my recollection from
> previous Usenet reading is that Comcast itself uses 10.* IP addresses
> internally for its own equipment.

I agree. The original poster mentioned Charter, but Comcast is probably the
same: the 10.0.0.0 network is for SNMP (or other proprietary uses I can't
guess at), and doesn't leave the cable.

> I further seem to recall that Comcast
> is one of the cable companies that has a "no servers" policy and
> that they attempt to enforce that policy by having their equipment
> "scan" (attempt to open) some of the common server ports on all the
> user machines. If my recollections are correct, then the packets could
> represent Comcast itself checking to see whether you are running servers.

That's very unlikely: no "server" is going to respond to a "10" IP address,
since each customer gets a routable IP address and would only answer probes
sent to the routable address, not the "10" address assigned to the cable
modem.

I'm willing to be proven wrong, but I don't see the logic in your
explanation.

William

--
William Warren
(Filter noise from my address for direct replies.)

In article <Ej7Wc.38782$Fg5.11673@attbi_s53>,
William Warren <(E-Mail Removed)> wrote:
:> I further seem to recall that Comcast
:> is one of the cable companies that has a "no servers" policy and
:> that they attempt to enforce that policy by having their equipment
:> "scan" (attempt to open) some of the common server ports on all the
:> user machines. If my recollections are correct, then the packets could
:> represent Comcast itself checking to see whether you are running servers.

:That's very unlikely: no "server" is going to respond to a "10" IP address,
:since each customer gets a routable IP address and would only answer probes
:sent to the routable address, not the "10" address assigned to the cable
:modem.

As I recall, at least one of the large cable companies in the USA
assigns 10.* addresses as the customer IP addresses, doing NAT translation
at the network edge. So 10.116.73.53 (for example) could -be- the
outside IP that was assigned through DHCP. If you aren't running a server
[if you aren't allowed to run a server by your ISP contract either],
then you are only making outward connections [with the exception
of a few protocols such as ftp and SIP, which there are "fixup"s for]
and it doesn't matter to you, the end user, that you are using a 10.*
IP that is being translated at the edge of the network.


Besides, if you check the original posting, you will find that the
logs shown by the OP only show one IP address, and that IP address is
obviously the source IP of the packet that was blocked (and no
ports were shown). If the OP was in fact running a server, then the
server software -would- reply to the 10.* packet unless the OP had
taken the time to specifically block those packets.

There is absolutely NOTHING magic at the operating system level
of any OS I am familiar with, that requires extra work or
extra privileges or magic attributes in order to receive packets
sourced from one of the RFC1918 or ARAN reserved IP ranges. If the
packet makes it as far as your equipment, your equipment is going
to receive the packet unless you have those packets specifically
blocked, and it is going to respond if appropriate. If your ISP is
doing it's job, then that response packet is not going to leave the
ISP's network, and so isn't going to make it "back" to wherever the
originator is, but that's a different matter.


:> Thus, a 10.* packet could have originated anywhere in the world that
:> chooses to disregard the "do not let them leak out" clause, and make it
:> over to you through a chain of providers who do not impliment the
:> "please do not let them leak in either" clause.

:I don't think that's a realistic scenario. The "chain of providers" would
:have to have agreements, and router tables, in place to make it possible,
:and I'd be very surprised if any ISP would expose their network to that kind
f unaccountable traffic and the risk it represents.

It *is* a realistic scenario. Follow some of the news.*abuse
newsgroups sometimes. I have seen a number of complaints from people
saying that their providers are letting in 10.* packets, and have taken
it up the chain with their provider only to be told that the provider
has NO intention of changing the situation.

Remember, 3/8 thru 15/8 except 10/8 are all assigned and routable
(1/8 and 2/8 are reserved), so it would be a temptation to peer
using a single /4 CIDR instead of a dozen /8's.

Some of the companies have given the excuse that their peering
agreements don't -allow- them to block any incoming packets.
[Such a situation could have evolved through failover arrangements
in which one ISP agree's to take on all of another ISP's traffic
in case of emergency -- and if the second ISP allowed 10.* within
it's network boundaries, then the 10.* then effectively leaks
over to the other ISP...]


news.*abuse has had a number of people crusading to get ISP's to
block incoming 10.* packets at their network edge, but the problem
persists. Some of the ISPs are actively resisting (follow the money!).
You'd think they'd be egar to block 10.* to cut down on the number
of anonymous virus triggers and such, but many of them are NOT co-operating.
A 10.* source'd packet you receive really might have come from nearly
anywhere, not just within your own ISP's network. It's a serious
problem that some people have spent serious amounts of time to try
to get the ISPs to fix, and the battle is definitely not won yet.

--
Studies show that the average reader ignores 106% of all statistics
they see in .signatures.