[afnog] [AfrISPA.Discuss] Securing our network

[Rob Thomas]

Hi, team.

Great advice, Mark!  I have only one bit to add/highlight.

Regardless of your mitigation strategy, gear, and capacity, eventually 
you will be visited by a DDoS that causes pain.  Having the ability to 
monitor and analyze the attack is crucial, of course.  The next step is 
to reach out to the wider community for help.

We see quite a few DDoS attacks each day.  Most go unnoticed because 
they don't exceed the threshold for pain.  E.g.:

    <http://www.team-cymru.org/Monitoring/Graphs/>
    * Scroll down to "Daily DDoS Attacks"

When the attacks do hurt, you'll need to reach out to the wider 
community to help mitigate the attacks closer to the sources.  Be ready 
with timestamps and time zones, ports, protocols, IPs, and any other 
bits that would be helpful in analyzing flows, crafting ACLs, or 
injecting null routes.  There are a variety of communities, such as 
nsp-sec and FIRST, and you might consider joining them.  Perhaps a 
nsp-sec-africa would be useful?

There is no 100% solution for DDoS mitigation, so we need to work 
together.  Feel free to ping on us (team-cymru at cymru.com) if we can 
help.  We have a lot of insight that might be of use, and we're happy to 
share.

Thanks,
Rob.


Mark Tinka wrote:
> On Monday 28 April 2008, Global One Solution wrote:
> 
>> I am sure you know well, ACL alone does not protect you
>> ANYTHING, unless you willing to block legitimate traffic.
>> You are really in the mercy of your ISP. If your ISP is
>> not placing the ACL in the edge router, what good your
>> ACL will do?  all the hacker need is a way to flood your
>> link, and they can take you tout of service. so let's say
>> you even place CiscoGuard(which i agree it's expensive)
>> and i m not saying this is the solution, but even if you
>> place some intelligent device in behind your CE router,
>> you will not be given the opportunity to study the health
>> of the packet, since the hackers goal is just to take you
>> out of service.  I am really advocate a VERY close
>> relationship between the *customer *and *ISP*.  RTB
>> (Remote Trigger Blockhole) is also another feature that
>> kind of helps clients
> 
> Protecting against DoS and DDoS is not easy and is as much 
> dependent on good networking practices as it is excellent 
> NOC procedures.
> 
> The first thing to have is the right tools, tools that will 
> help detect anomalies quickly, e.g., NetFlow, cFlowd, MRTG, 
> Cacti, Ourmon, Nfsen, commercial products, e.t.c.
> 
> Once you have that, having a trained NOC that knows what to 
> do, step-for-step, is crucial. If your NOC are slow or do 
> not have proper procedures to follow, all your fancy 
> equipment is useless.
> 
> The next is looking at how best to mitigate the attacks. 
> Larger ISP's do this with money, i.e., use hardware-based 
> routers (forwarding packets using ASIC's and/or network 
> processors, rather than software processes) + huge 
> bandwidth. Probably not an option for a small ISP, but then 
> again, typically, large and small ISP's see different 
> attack profiles (although you shouldn't always take this 
> for granted).
> 
> For customers whose upstreams have fat pipes and big 
> hardware-based platforms, you can purchase anti-DoS 
> services where the upstreams will have a fairly low 
> utilization threshold, e.g., 40% (or more) of all bandwidth 
> should remain available at all times. They can then use 
> this extra bandwidth to suppress any attacks heading your 
> way, thereby freeing up YOUR pipe to them.
> 
> Note that destination-based blackholing is faster to 
> implement, but, for all intents and purposes, completes the 
> DoS attack anyway :-).
> 
> Source-based blackholing is possible, but harder as many 
> attacks these days are DDoS-based, i.e., the attack 
> originates from multiple sources.
> 
> Simple things you can do within your network to mitigate the 
> spread of such occurrences (in addition to the points in 
> the first few paragraphs, above):
> 
> 1. Deploy BCP-38 on your border, peering and edge routers.
> 
> 2. Compliment this with RFC 1918 blocking.
> 
> 3. Add RFC 3330 blocking.
> 
> 4. Use uRPF (loose and/or strict, depending on where you
>    place it).
> 
> 5. Use prefix lists or route filters for BGP sessions with
>    your customers (remember the PCCW-PTA incident?).
> 
> 6. Have a community-based blackhole policy, with a dedicated
>    blackhole router, i.e., remote-triggered blackholing, as
>    you mention above.
> 
> 7. Use RPSL to manage external peering filters.
> 
> Cheers,
> 
> Mark.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> afnog mailing list
> http://afnog.org/mailman/listinfo/afnog

-- 
Rob Thomas
Team Cymru
The WHO and WHY team
http://www.team-cymru.org/