DOSsing the PHPIDS/.NETIDS
Mario Heiderich
I recently asked myself what we could do to make sure an application
protected with the PHPIDS can't be DOSsed by the PHPIDS.
Imagine the following situation:
- An attacker knows that the PHPIDS is working on an application.
- He crafts overlong attack strings - around 8K-10K chars via POST -
filled up with high-impact vectors
- He creates a script which is capable of performing request over
Request.
result would be that PHPIDS scans every incoming request - needs
pretty long time due to the ultra high amount of vectors... dozens/
hundreds of mails are sent out, server load might raise sky high etc.
What do you think - is this an issue we should take care of? What
could we do to prevent getting DOSsed?
Greetings,
.mario
Lars Strojny
Am Montag, den 23.07.2007, 05:51 -0700 schrieb Mario Heiderich:
[...]
> What do you think - is this an issue we should take care of? What
> could we do to prevent getting DOSsed?
First of all: never send mails when you should log. The rule is simple:
when an error occurs, it will likely occur more often. So: never send
mails, just log or send just *once*. The second thing is, that the
component before the webserver is the one to handle (d)DOS attacks. It
in the hand of the firewall to detect similiar IP packages and to
implement rules against dossing. Aside from optimizing regular
expression via benchmarks, there is nothing to be done in PHPIDS.
cu, Lars
Martin Hinks
The idea behind this is that when the IDS hits 50 as an impact level
it stops scanning...
Martin
christ1an
>> First of all: never send mails when you should log. The rule is simple:
>> when an error occurs, it will likely occur more often. So: never send
>> mails, just log or send just *once*.
Well, can't fully confirm that. I would make sense to send such report mails
to additional e-mail accounts that are only used for these purposes.
If someone uses his private mail addresses, his fault.
Bottom line is, there is nothing we can do except of documenting this
problem properly on the site.
Regards,
christ1an
am Dienstag, 24. Juli 2007 um 12:05 schrieben Sie:
christ1an
email logger is used, the users inbox can't be spammed by dozens of
alerting mails.
Users who just copy & paste our example.php might fall into this trap
since its not documented at all. One doesn't think about this issue in
first place but surely it will be annoying once it happens for the
first time.
I suggest to implement a simple cookie and IP based protection,
enabled it by default and document how to disable or customize it.
Everybody okay with this?
- christ1an
am Dienstag, 24. Juli 2007 um 12:05 schrieben Sie:
> What about setting an option for "maximum impact level" (eg. 50).
Mario Heiderich
Lars Strojny
Am Sonntag, den 12.08.2007, 23:08 +0200 schrieb Mario Heiderich:
> Yep - definitely. The cookie/IP combo should cover most approaches.
No, sorry. There are certain reasons, why the IP is not the unique key
you should relay on. Reason a: some IPSs are still proxying
HTTP-traffic, which means there are a lot of users behind the same IP or
behind random IPs. The other thing is, that we should not focus on DOS,
which is trivial to block, but on DDOS, which is much harder. I can't
find a way how to fix this in PHPIDS, it's the responsibility of the
firewall.
cu, Lars
--
»Die Glorifizierung der prächtigen underdogs läuft auf
die des prächtigen Systems heraus, das sie dazu macht.«
-- Theodor W. Adorno, »Minima Moralia«: They, the people
Lars Strojny
Engelsstr. 23
51003 Cologne
Jabber/Mail: la...@strojny.net
Weblog: http://usrportage.de
christ1an
> you should relay on. Reason a: some IPSs are still proxying
> HTTP-traffic, which means there are a lot of users behind the same IP or
> behind random IPs.
Right but there is pretty much no reason for why we should care about
that issue Lars. You are arguing about an aged developer problem
(authenticating users efficiently) that has nothing to do with the
goal we are striving here.
Our objective is and remains to protect clients from a massive amount
of spam mails, sent through an obvious vulnerability within a 3rd
party framework which is PHPIDS.
Now estimate the chances that there are two attackers on a site, both
not accepting cookies and both having the same IP and the same user
agent. Although this case could possibly occur in theory, I think it
is highly unlikely that it will occur in practice, considering the
fact that the e-mail logger probably won't be used on high traffic sites
anyway.
So I will certainly not let this hole untouched. Therefore I suggested
to provide a basic but sufficient default protection that however can be
disabled at whim.
> The other thing is, that we should not focus on DOS,
> which is trivial to block, but on DDOS, which is much harder. I can't
> find a way how to fix this in PHPIDS, it's the responsibility of the
> firewall.
I'm not even referring particularly to DOS attacks here. I'm talking
about spam. Of course people like you or me would never forward such
report emails to our private mail account which we use for talking
with friends. Though this doesn't change the fact that the majority of
users doesn't even have more than one email address which could now
possibly be overfilled with report emails. I think this is clear now.
Regards,
- christ1an
am Montag, 13. August 2007 um 01:16 schrieben Sie:
Lars Strojny
Am Montag, den 13.08.2007, 11:03 +0200 schrieb christ1an:
[...]
> Right but there is pretty much no reason for why we should care about
> that issue Lars. You are arguing about an aged developer problem
> (authenticating users efficiently) that has nothing to do with the
> goal we are striving here.
Yes, this problem also occurs when it comes to authentication, but it
just demonstrates that identifying one user by an IP is not sufficient.
When someone tries to start a DOS attack via an ISP like AOL, you are
going to be DDOSed in fact.
cu, Lars
Martin Hinks
the spam logging/user identification problem. This is an issue but in
the long run there is actually no foolproof way to prove that one user
is the same as another - as has been said IP is not good enough....
My suggestion of a "maximum impact level" was in regards to people
submitting ultra long strings to the IDS that take a long time to
process - in effect a protection measure against DDOSsing the IDS by
making the code do too much work as it stops when the maximum level is
reached. I still think this is a good idea - the maximum level can be
specified by the user depending on the maximum impact level that they
check for and this will prevent the IDS from consuming too many
resources...
Martin
Mario Heiderich
spammed and I definitely would like to see that feature in one of the
next releases. the question is: How are we going to manage the storage
of the needed data? Shall we work with a flatfile or rather chose a
more flexible solution like SQLite? With the last mentioned way we
could also provide a basic DB LOG wrapper - independent from existing
DBMS structures of the application the PHPIDS is used in.
Mario Heiderich
Just a short note. Christian and I talked yesterday evening about this
issue again and we developed a good way to deal with spam which he
implemented yesterday too. We now have a maximum amount of mails that
can be send in a certain timeframe - if the amount of mails rises too
high the developer will only receive a digest mail for future attacks
from the attackers IP.
Greetings,
.mario
On Aug 20, 6:49 pm, Mario Heiderich <Mario.Heider...@googlemail.com>
wrote:
Gareth
1. Detect DOS attacks.
2. Identify attackers.
3. React to attackers delay/disable/timeout.
On Jul 23, 1:51 pm, Mario Heiderich <Mario.Heider...@googlemail.com>
wrote: