> From: Don Tuer <[EMAIL PROTECTED]>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: Why isn't a NAT secure?
> Date: Wed, 13 Sep 2000 06:04:41 -0400
> Sender: [EMAIL PROTECTED]
>
> I'm not sure about IP spoofing. Since we use an private address (10.x.x.x)
> won't the ISP routers have a filter for this source address?
They *should*. But, a number of providers DO NOT implement completely.
I'm fighting about this with one provider right now.
They use RFC-1918 addresses internally. And thus, there _is_
"internal" routing for (at least some) of the RFC-1918 address-space.
They filter RFC 1918 addresses, if used as either "source" or "dest",
at their *EXTERNAL* connection to the Internet *only*. They do _NOT_
filter on RFC 1918 _source_ addresses on traffic coming _from_ their
*customers*.
Now, when I get an 'attack' or 'attack precursor' signature, originating
from RFC-1918 address-space, and they claim it's part of th 1918 space
that they 'do not use' -- then the packets must be originating -inside- the
provider's border barriers, but 'outside' their 'internal' space -- i.e.,
from one of their other -customers-, But, the provider, themselves, cannot
tell where it's coming from, so as to figure out who to contact to get it
stopped. of course, 'scans' that originate from those addresses are
virtually useless to an attacker, unless he is actually _inside_ the
provider network (not just a customer of theirs), because he can't see
any responses to the scan.
They claim putting 'outbound' filters on all the customer interfaces, to
keep RFC-1918 source addresses from exiting to cust nets, would be an
"administrative nightmare", to maintain.
And, obviously, they don't filter inbound from customer networks for
RFC 1918 source addresses. Presumably because of the same "nightmare".
And, presumably by the same ~logic~, they don't filter RFC-1918 *destination*
addresses originating from customer nets, either.
<*S*N*A*R*L*>
Now, there is some RFC-1918 source-address stuff that you do need to
let in. various ICMP "respoonse" and/or "error" messsages come to mind.
And any thing where you are, by *mutual*agreeement*, using RFC-1918 address-
space _across_ a border with another administrative domain.
And, potentially, *if* you're using RFC 1918 addresses internally on devices
that might send those types of response messages to _external_ origin traffic,
you would need to let those, and those messages *only*, 'escape" to the
outside world.
It's not rocket science, by any means, but it is *demonstrably*, "too much
time/effort/trouble" for _some_ providers to bother with.
I've decided I'm curious about the _real_ state of affairs on this subject
in the world at large. It's mini-survey time! This is primarily to
satisfy my own curiosity, I've got no commercial motivation in this.
Composite results will be shared with those interested.
Please keep all communications related to this *off* the firewalls
mailing list. Individual reportsa are probably _not_ of any interest
to at least 99% of the mailing-list subscribers.
If you're participating, email youre responses to:
[EMAIL PROTECTED]
If you'd like a copy of the compiled results, send a request to:
[EMAIL PROTECTED]
(if I get an insanely large number of requests, I may post a single
copy to the firewalls list)
And now, to the questions:
(for multi-homed networks, please answer separately for each provider)
0) Is this a full-time (i.e. 7x24) permanent connection to the Internet?
(i.e., _not_ a dial-up and/or dial-on-demand type connectin)
If it is not a full-time connection, you may skip the rest of the
questions.
1) Name of provider _____________________
(used only to match multiple reports
about the same provider )
2) Do you know _if_ this provider has a FORMAL POLICY on
filtering/blocking IP addresses and/or ports ? ___ Yes ___ No
3) If yes, do you know _what_ that policy is? ___ Yes ___ No
4) At the "Internet" gateway, do they block RFC 1918
'destination' address inbound ___ Yes ___ No
'destination' address outbound ___ Yes ___ No
'source' address inbound ___ Yes ___ No
'source' address outbound ___ Yes ___ No
5) Do they block RFC 1918 addresses even if it is in
an ICMP 'statue'/'error' message? ___ Yes ___ No
6) Does the provider user RFC 1918 addresses itself? ___ Yes ___ No
7) At the "Customer" gateway, do they block RFC 1918
'destination' address inbound ___ Yes ___ No
'destination' address outbound ___ Yes ___ No
'source' address inbound ___ Yes ___ No
'source' address outbound ___ Yes ___ No
8) Do they block RFC 1918 source addresses even if
it is in an ICMP 'statue'/'error' message? ___ Yes ___ No
9) Do they block/filter any other addresses? ___ Yes ___ No
(e.g. the MAPS real-time Blackhole List) (if yes,
please list)
10) Do they block/filter any specific ports? ___ Yes ___ No
(e.g. block MS NetBios, or restrict port 25)
11) Does _your_ operation use RFC 1918 addresses ? ___ Yes ___ No
12) Do you block RFC 1918
'destination' address inbound ___ Yes ___ No
'destination' address outbound ___ Yes ___ No
'source' address inbound ___ Yes ___ No
'source' address outbound ___ Yes ___ No
13) Do you block RFC 1918 source addresses even if
it is in an ICMP 'statue'/'error' message? ___ Yes ___ No
DEMOGRAPHICS (if you feel like it)
14) Aggregate bandwidth from this provider? __________
15) Approx average utilization of that bandwidth _______ %
16) Size of provider-supplied address-space if any ______
17) Size of 'portable' address-spaces, if any ________
18) Size of RFC 1918 address-space in active ________
use, if any
19) Est total number of machines on internal ________
network
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
