[WEB SECURITY] RE: 02/2009 WASC WAF thread

[Andre Gironda]

On Wed, Feb 11, 2009 at 6:52 PM,  <lucifer.yang at sti.com.tw> wrote:
>> I don't really care that much about phpbb or P2P server compromises.
>> They don't cost the US $1T per year.
>
> You are avoiding the problem.
> Their companies care since they make living from those activities.
> You cannot imagine the profit of a game forum here in asia.

Sorry, I guess that was a bit uncalled for.  You're right in a few
areas here.  I'm sure I could come with some suggestions that are
cost-effective besides "just WAF" for these scenarios.  Give us some
more information.

> And, ISPs offers dynamic IPs for people here.
> So for out ticket ordering system, IP cannot be blocked by any reason, and
> strong authtication is not allowed.

Run your own ISP.

>>> No, you are talking about L4 DoS, not L7.
>>> L7 DoS is not that simple.
>>
>> Sure it is.  HTTP connection starving is VERY similar to SYN flooding.
>
> No, syncookie, synproxy, etc are the common waies using in AntiDDOS device
> to dealt with L4 DOS,
> but cannot do anything about HTTP DOS.

Yeah except that SYN cookie and SYN-proxy don't work.  I suggest that
you are looking at the wrong Anti-DDoS devices.

>> Cisco uRPF or equivalent is nice, especially in combination with BGP
>> and multi-transit/customer/peer setup.  Blackholing IP ranges works
>> well, too.  I like the concept of blackholing your own IP space across
>> your provider.  Consider working closer with your ISP's.
>
> Cisco uRPF is useless here. Since in L7 DoS, no source IP is spoofed.

Agreed, but not every DoS/DDoS is always using valid IP's...  this is
useful sometimes.

> Still, I've mentioned IP-based is  really a bad idea for these companies,
> since it quuals to losing money.

Risk analysis.

> If you have the real experience dealing DDOS in a commercial company, you
> should understand better

Careful with what you say here.  I usually take this as a serious
insult.  If you knew anything about me or where I've worked, or what
I've contributed to whitehat CNA research, and anti-DDoS defense...

> ISP often respond that they can do something about L4 DoS, but can't stop
> any L7 DDoS, since they can't identify which source is a attacker bot.
> 100 different souce ip means they must talk to another 100 different ISP,
> and you want to do this every time you been DDoSed?

Identify the tool.  There are deep statistics to be had from full
packet capture, especially if you have a good timing source.  Use taps
instead of SPAN ports.

Don't trace-back the IP.  Trace-back the attacker tool.  Find the
command and control and exploit it to your advantage.  Fight CNA with
CNE.

> About Anti L7 DDoS,  packet sampling for detection and mitigation is not a
> point here.

Um... yes it is.

> Ourmon? tcpdump? monitoring  and analysis then block easily? not a thing
> pratical in reality.

It's very practical.  Have you tried it?

> First you should turn on logging on every HTTP and SQL Server with "LOG
> everything", it means you should log every GET/POST/PUT request and response
> cotent in your web server, and enable full auditing on db server.
> In fact, only turn on the auditing with default, kills many our customer's
> db server in a short time.
> Even you solve these ,  you must hired really good and exprencied people
> 24x7 watching the minotor, and make sure they don't miss anything.

Logging is important, but I agree that it's not everything.  I
suggested the above because a simple SIM/SEM like Splunk deals well
with syslog data.

> Track and Take down the bots ? meaningless.

Not meaningless.

> And we shoudl do this on our own, since police won't help to do this
> tacking.

You got it.  Maybe the US Secret Service will help you.  I have no
idea how this works in other countries.  There are many organizations
out there that provide this as a service, however, they are often the
target of attackers.  For example, CastleCops is no longer with us.

> Find the attacker? yeah we already know who he is, since we got the
> extortion mail.
> But the police won't help here either, esecially the attacker is from
> another contry.
> And more,  most attackers comes from THE country our country cannot deal
> with.

WAF alone is going to help you against these adversaries?

> We know what WAF can do and what WAF can't.
> If their problems all fall into  "what a WAF can do" area,  WAF is an
> alternative option we will give them.

Look, WAF can help, but only in the hands of a real expert.  You won't
get that in a year.  So leave it in monitor-only mode until you know
that you're not blocking good traffic.

Ok, I'm going to say something that is going to blow all of your minds away.

In almost every early IPS, early Anti-DDoS efforts that I was apart of
in the 1998-2005 era...

The organizations would NEVER believe that the IPS or Anti-DDoS
appliance was the result of a MAJORITY of the down-time.  They simply
wanted these devices to work.  They wouldn't put them in monitor-only
mode.  They wouldn't even consider it.  They wanted blocking and they
wanted blocking NOW.

Do not rush into these kinds of projects.  There is a lot of effort
required in the lab, and moreso in production, to understand the
intricacies of what happens during an attack, and whether the
inline-device is preventing that attack or not.  During an attack, is
the device crippling itself?  I know that some WAF vendors have a
"per-rule CPU evaluation" mode, but do you believe it?  If you do,
you're stupid.

Trust, but verify.  In the case of WAF, DO NOT TRUST.  Verify
everything these vendors are saying and dig way into the internals.
Lab it up for years.  I understand that people like Arian have
invested TONS of time into making these things work, and that in some
circumstances - they can work.  But nowhere to the degree that anyone
is saying today.  Arian is also focused on making WAFs work for his
companies' purposes, which is to sell yearly assessment services.  He
is not focused on the software assurance and performance of these
products to the degree that an operational organization would be (or
should be) because he is blinded by his desire to make his stuff work
with their stuff.

As explained in this email, you are better off IDENTIFYING what and
who is attacking you instead of attempting to block.  If you
understand what technology your adversaries are using against you
better than they do, then you KNOW YOUR ENEMY.  WAF vendors do not
know this.  They can't.  They aren't you.

In all honesty, there are other factors to consider.  If your enemy
knows that you are blocking him, he will attack the wall by examining
the wall.  If you don't put up a wall, and instead gather intelligence
on your enemy, then you can examine how he examines things.  There is
an entire intelligence layer (OPSEC, IOPS, etc) to consider before
letting your adversaries know that you know that they are adversaries.

Intelligent Adversaries know about WAFs.  They are attacking them directly.

Cheers,
Andre

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA