[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-opsec-infrastructure-security-01 - Infrastructure Hiding
On Apr 27, 2007, at 1:33 PM, Smith, Donald wrote:
Donald.Smith@qwest.com giac
-----Original Message-----
From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On
Behalf Of Tony Rall
Sent: Thursday, April 26, 2007 7:16 PM
To: opsec@ops.ietf.org
Subject: RE: draft-ietf-opsec-infrastructure-security-01 -
Infrastructure Hiding
On Thursday, 2007-04-26 at 18:44 CST, "Smith, Donald"
<Donald.Smith@qwest.com> wrote:
From rfc 1918:
Some examples, where external connectivity might not be required,
are:
<snip>
"Interfaces of routers on an internal network usually do not
need to be directly accessible from outside the enterprise."
<snip>
"Because private addresses have no global meaning, routing
information
about private networks shall not be propagated on inter-enterprise
links, and packets with private source or destination addresses
should not be forwarded across such links. Routers in networks not
using private address space, especially those of Internet service
providers, are expected to be configured to reject (filter out)
routing information about private networks. If such a
router receives
such information the rejection shall not be treated as a routing
protocol error."
So the way I read that as long as we don't provide a path
back to the
rfc1918
space and don't expect external connectivity directly to
the 1918 space
this is
within the guidance of the rfc.
Not in my mind. In no way is an ISP's network private (ok,
parts of it
might be, but those parts would not be on the path of transit
traffic).
The transport gear is private in most ISPs.
As we switch to MPLS as transport why shouldn't it be private?
Why should would you expose the managment or control plane to
customer's
beyond the PE?
While that clearly says enterprise I believe it can be applied here.
Your statement "assuming you ever source packets with these
addresses to
targets outside your "private" network" is of course correct.
But when mixed with other infrastructure core hiding techniques it
should be
possible to never source traffic outside your "private network".
But if you never source such packets, you're breaking all
sorts of RFCs -
mainly related to icmp.
Making portions of your network, such as core routers,
"untargetable"
specifically making the control plane addresses not
routable externally
makes
it EXTREMELY difficult to attack those portions.
Certainly it's still possible to target them. Perhaps you
can't overload
them by direct addressing, but all that's necessary is to get
traffic to
go through them.
"Fill the pipe" attacks are very difficult to prevent but also very
noticeable.
In many cases you can ratelimit those types of attacks.
This isn't meant to prevent that. It is meant to prevent direct
attacks
against the router's managment or control plane.
Successful attacks against the mgmt or control plane of the routers
can
involve several orders of magnitude less packets that a bandwidth
resource attack. They are harder to detect at the edges.
Correctly implemented edge ACLs should be blocking unexpected traffic
destined to the infrastructure -- it is possible to forget / mess up
an edge ACL, but most kit these days will do receive or loopback ACLs.
Regardless, I never buy the argument that adding any subtle amount of
protection for my network justifies breaking all kinds of
other things.
This is not subtle.
Done correctly it prevents nearly EVERY resource exaustion attack
against the infrastructor
except the bandwidth resource exaustion attacks.
Yes, but done incorrectly it causes huge amounts of pain and
suffering.... and getting it done correctly is tricky, especially if
you ever need to talk to anyone else...
If it's really thought otherwise, I don't know what stops those
who do from
using the ultimate firewall - wire cutters.
The fact they we wish to make money selling bandwidth:)
you have probably already ratelimited
icmp unreachables.
Nope, never done this. But that is not nearly as bad as
cutting them out
completely. I can justify some collateral damage in response
to an actual
attack, but I can't condone blindly blocking (whether by filtering or
using invalid addresses) of legitimate traffic.
It helps prevent your routers from being fast DDOS reflectors.
When your routers are fast reflectors they will be used to reflect
DDOS
traffic.
The fact that routers make very fast dos reflectors was discovered
years
ago.
Errr... My routers actually make fairly poor DoS reflectors -- they
either have small CPUs or have a fairly small pipe from the control
plane to the data-plane, or both...
I DO however have a heap-o-servers that have fast CPUs, fast NICs and
bandwidth to spare -- by the above logic I should be hiding all my
servers?
The first one I was aware of was SMURF which really used the router to
fan out the icmp traffic destined to the broadcast address. I
assume you
disabled directed broadcasts.
Not quite -- the router just forwards the packet like normal --
because it is a broadcast packet, the router fills in the broadcast
L2 address (instead of a specific machines address) and ships the
packet on its merry way. The router is not doing any fanout -- it is
the machines on the subnet that are providing the amplification.
Routers are fairly slow beasties for doing things like generating
packets -- I can happily point you to piles of emails from people
complaining that when they traceroute through network Blah they get
packetloss (but their connection to servers on the far side of Blah
is fine...) -- routers rate-limit things to protect themselves, not
reflection targets.
From rfc 1812
" A router MUST classify as network-prefix-directed broadcasts all
valid, directed broadcasts destined for a remote network or an
attached nonsubnetted network. Note that in view of CIDR, such
appear to be host addresses within the network prefix; we preclude
inspection of the host part of such network prefixes. Given a
route
and no overriding policy, then, a router MUST forward network-
prefix-directed broadcasts. Network-Prefix-Directed broadcasts MAY
be sent.
A router MAY have an option to disable receiving network-prefix-
directed broadcasts on an interface and MUST have an option to
disable forwarding network-prefix-directed broadcasts. These
options
MUST default to permit receiving and forwarding network-prefix-
directed broadcasts."
This was later changed by http://rfc.net/rfc2644.html but most of us
turned off directed broadcasts before rfc2644 was published.
The next one was the one I refered to against GRC where the attacker
spoofed GRC ip addresses and sent them towards routers on BGP ports.
That attack was spoofed syn's no amplification. It would have (and
does)
work just as well today if you send back a icmp port/host
unreachable to
the spoofed src address.
The attack still gets to hide the attacking systems behind real fast
routers:(
Yup, and the attacker would be much better off using the millions of
web servers that exist -- they usually have more CPU and bandwidth,
they have to respond and they are usually not all that closely
monitored.
To stop people from doing negitive scanning of our
infrastructure I require SILENT drops (not tcp reset no icmp
unreachables) from
network vendors.
This is really pushing the "security by obscurity" modus. I
see no value
in it, and plenty of problems.
Me too... Thats just horrid....
Most of the people that I have met who *are* in favor of
infrastructure hiding seem to be in favor of it because they don't
have much faith in things that block inbound traffic towards their
management interfaces -- this is usually because they did a really
bad job in laying out their addressing (or inherited a network like
this) and have management IPs scattered around all over the place --
NB: I am not implying that people involved in this conversation are
in that boat...
It is sometimes refered to as stealth mode.
Why double the effects of a DDOS attack?
Why would you want your router to tell the world what ports are
closed?
So they can figure out what ports are open?
Why would I allow people to send packets to my router that I am not
expecting? I don't hide my infrastructure, but I do ACL off all
traffic destined to my infrastructure (ok, not literally ALL... I
allow echo-request, some ports for traceroute, BGP from neighbors, etc).
No rfc that I know of requires I publish/advertise all the IPs of a
router.
Certainly not, but those addresses that communicate outside
your network
should be legitimate and reachable.
Agreed those that communicate with our customers (edges or PEs) are
legitimate and reachable by the directly connected customers. No IP
address other then our managment addresses have authorization or a
legitimate reason to access the managment plane of the routers so that
is restricted. Major portions of the control plane are also
resticted to
address space that requires access to that control plane service.
Those that are part of the MPLS transport have no need to communicate
with any ip other then a few qwest ips for management and control
plane.
PTMUD has been blocked in many networks as a result of this issue.
Yes, and I consider that a significant negative against what has been
proposed (and any other techniques that cause the same
problem). I do not
consider this a "best" practice or even a slightly good practice.
Me neither!
Don't get me wrong - I feel the other sections (other than
6.x) of the
draft might be beneficial, but I wanted to strongly object to 6.
Me too!
This is a nice draft -- it outlines useful info and suggestions for
the community, but section 6 is starting to feel like a holy war.
I cannot really see everyone coming to consensus on this and feel
that section 6 should be dropped...
I appreciate that and have been enjoying this discussion.
Thanks!
--
Tony Rall
This communication is the property of Qwest and may contain
confidential or
privileged information. Unauthorized use of this communication is
strictly
prohibited and may be unlawful. If you have received this
communication
in error, please immediately notify the sender by reply e-mail and
destroy
all copies of the communication and any attachments.