[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Your counsel on defeating DDOS Attacks

I'm hitting reply to all intentionally to spur discussion -

> -----Original Message-----
> From: AlanPaller@AOL.COM [mailto:AlanPaller@AOL.COM]

> Key Trends
> ----------------

> The recent attacks against e-commerce sites demonstrate the
> opportunities
> that attackers now have because of several Internet trends and related
> factors:
>
> ·   Attack technology is developing in an open-source
> environment and is evolving rapidly.

Attack technology also develops in a closed source environment.  In fact,
many attacks remain known to only a small group until they leak.
Additionally, some attack technologies are known as network security
auditing tools, and often leak into the wrong hands.  One difficult aspect
of the problem is that I have the same need (and use similar tools) to
identify vulnerable systems as an attacker would.

> ·   At any point in time there are hundreds of thousands of
> systems on the Internet with weak security.

This is the essential problem.  It is difficult to build an attack network
if you do not have large numbers of machines you can compromise.  Reducing
this problem is at the heart of pro-active measures to lower the level of
vulnerability.

Due to our (MS) extremely high visibility, a single compromised host on our
network can turn into a public relations issue quickly.  Thus we pay more
attention than most to our external user network.  Although we have much
that we could improve, we find that regular network security audits, coupled
with good user contact information, reduces the number of vulnerable systems
rapidly.  I believe part of the solution is for any organization that
provides internet connectivity (esp. persistent connections) to conduct
routine audits of their user base, and get problems corrected.  Our
situation is somewhat unique, but any ISP should not want their network
being used as a platform to attack others.

I also believe that we should come up with a list of suggested best
practices for someone providing internet services, and some way to encourage
people to follow them, and perhaps discourage people from ignoring them
(e.g., not route their packets).

> ·   The rapid increase of direct-connect homes, schools,
> libraries, and other
> venues without trained system administration and security
> staff is increasing
> the number of vulnerable systems and will allow attackers to
> continue to add
> these systems to their arsenal of captured weapons.

This is why I believe that network security auditing is an essential
service, and has to be part of the solution.  Until we can design systems
which are self-healing from a security standpoint (a highly non-trivial
task), we have to have a way to find these systems and alert the users.
Even when we do start making keeping systems more secure user-friendly,
we'll still have older systems on the network for many, many years to come.

> Immediate steps to reduce risk and dampen the effects of attacks

> ·   Problem 1: Spoofing

> This activity is often called egress filtering.
...
> ISPs may also be
> able to stop
> spoofing by accepting traffic (and passing it along) only if
> it comes from
> authorized sources. That is often called ingress filtering.

Actually, there is more to it than that - you also do not want any packets
coming into a network that have a source address which is also on the inside
- these packets cannot be legitimate, unless you've got some really messed
up routing tables somewhere.  Some spoofing attacks have involved sending a
host a packet that has the same source and destination, causing the host to
go into a loop.  Many sites could implement incoming anti-spoofing rules,
but cannot easily implement rules that restrict incoming packets to some
known set of networks - our web site is much too high a traffic level, and
legitimately serves a lot of networks.

One caveat here is that when you start applying lots of router rules,
performance can drop, and requires much more expensive hardware.

> ·   Problem 2: Broadcast Amplification
> The attack goes by the name Smurf.

I believe there are other attacks in this category with different names, and
are variations on the same technique.  That one uses echo request and reply,
but I could easily do the same using UDP packets and ICMP unreachables.  At
the very least amend this to "One known attack in this category is known as
Smurf."

> ·   Solution: User organizations should block traffic sent to
> "broadcast"
> addresses so that their systems cannot be used to amplify
> these Smurf attacks.

This has to be done at all routers within a network, since what is a
broadcast address depends on the subnetting rules.  For example, 10.0.0.192
could be a broadcast address, but an upstream router won't know whether it
is or not.

I'm not sure how widespread use is, but broadcast addresses do sometimes
have legitimate uses.  We would break that functionality by implementing
this suggestion.  It might be worth the trade-off, but we need to understand
the cost/benefit.

> ·   Problem 3: Dial-Up User Spoofing

> ·   Solution: ISPs, universities, libraries and others that
> serve dial up users should ensure that proper filters are in place to
> prevent those dial-in connections from passing falsified addresses.

This is a good step, but another step is that dial-up providers should be
required to archive logs for a greater period of time.  It often hampers
investigations when there is no way to map a dial-up IP address back to the
user.

> ·   Problem 4. Unprotected Computers

> Many user organizations allow their computers to be
> vulnerable to take-over
> for distributed denial of service attacks. When those
> computers are used in
> attacks, the carelessness of their owners is [...]

The owners are not always careless.  They are often ignorant, and frequently
have just made mistakes.

> c. Sun users should ensure that rpc traffic is
> allowed only from
> management systems.

I would not get into specific vendor actions here.  We could make the
document very large if we get into details like this.

> ·   System administrators should deploy "best practice" tools
> including
> firewalls (as described above), intrusion detection systems,
> virus detection,
> and software to detect unauthorized changes to files. This
> will reduce the
> risk and increase the confidence in the correct functioning
> of the systems.

Security auditing tools are also essential.

> ·   Test deployment and continue research in anomaly-based,
> and other forms
> of intrusion detection

IDS only tells you what is trying to get you.  Auditing tells you what will
get you, and is the same thing the attackers are going to do to determine if
they can get you.  IDS is also a somewhat immature technology, and it will
sometimes miss things for a variety of reasons.  It is also difficult to
employ in high-bandwidth situations.

> ·   Sponsor research in policy that leads to uniform security
> policy to
> protect systems and outline security responsibilities of
> network operators,
> Internet service providers, and Internet users.

I agree that this is very important.  A lot of network security is a systems
management problem - locating problems, determining the owner, and getting
it fixed.

[many points I agree strongly with snipped]
Page Last Updated or Reviewed: May 22, 2007