No there isn't a rule saying you must provide a security solution with
a single tool, but... you should aim to make a single product as secure
as possible.
What if you had a security vulnerability in iptables (or whatever
firewall
you used), and their response was to just use something upstream from
that
to filter out that vulnerability? That tbh seems like the same thing as
saying that we shouldn't fix an issue in an application but instead just
"patch" it in the upstream network by banning it.
What if there is a flaw in fail2ban, say it stops bad traffic, but also
traffic you did want, or traffic that is bad is not stopped (this is the
idea of false positives/negatives, which happens which can happen with
any deterministic tool in a stochastic space such as network
connections).
How can we rely on fail2ban so intensively in this instance?
Cheers,
Hugh
On 2013-07-18 10:51, Ivan Kurnosov wrote:
The thing is - security is a broad field. There is no such a rule that
"you have to provide a security solution using a single tool".
If you want to waste your webserver resources instead of simply
banning via firewall - it's up to you, but it's a rule of thumb.
On Thursday, July 18, 2013 9:51:18 AM UTC+12, Hugh Davenport wrote:
If I
use a project that I must rely on a third party tool /foobar/ *just*
to
get
the project in a secure stable state, then that project is not doing
it
right.
Cheers,
Hugh
On 2013-07-17 21:26, Ivan Kurnosov wrote:
2. In government just a regular people work, not gods. They have
their
own preferences :-)
3. As I said - it's reeeeeeeeeeeeeeeally trivial
The thing is - even if there was no such "vulnerability" - you
still
would be able to "DOS" silverstripe-based site with a bunch of
requests just because the cost of generating a request is
dramatically
higher than the cost of a generating responses.
So the "issue" is overrated. For someone who can google and is not
a
total dumb - any level7 attack issues can be solved easily.
On 17 July 2013 21:20, Petah <[email protected]> wrote:
There are a few questions to raise here:
1. Why can a member of the public flush the cache?
2. Why has the NZ government chosen Silver Stripe over something
like Drupal, or other alternatives?
3. Does the government service providers have the knowhow and
capabilities to detect and prevent such attacks?
4. If someone did manage to use this, or something similar, what
websites would it effect and how would the public be affected?
On Wed, Jul 17, 2013 at 9:07 PM, Ivan Kurnosov <[email protected]>
wrote:
It's actually pretty obvious that non-cached page takes longer to
generate (while I agree it's weird they provide a switch to flush
the cache) :-) Anyway, it's well known that the most resources
consuming part of almost every project is captcha generating
endpoint.
On 17 July 2013 21:04, Christopher Tombleson <[email protected]>
wrote:
True. But it a silly code error should have never been there in
the
first place.
On Wed, Jul 17, 2013 at 8:59 PM, Ivan Kurnosov <[email protected]>
wrote:
It's a pretty script-kiddy attack that can be defended in minutes
using dummy fail2ban, after rule is applied your traffic would
produce literally no noticeable influence on the project
On Wednesday, July 17, 2013 6:16:40 PM UTC+12, chtombleson
wrote:Hi,
I have recently noticed a DOS vulnerability in Silverstripe 3,
I did some testing and it turned out I was right,
you can find my results here:
http://blog.cribznetwork.com/2013/07/silverstripe-3-dos-vulnerable/
[1]
[1]
Cheers,
Christopher Tombleson
--
--
NZ PHP Users Group: http://groups.google.com/group/nzphpug [2]
[2]
To post, send email to [email protected]
To unsubscribe, send email to
[email protected]
---
You received this message because you are subscribed to the
Google
Groups "NZ PHP Users Group" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out
[3]
[3].
--
Christopher Tombleson.
http://cribznetwork.com [4] [4]
--
--
NZ PHP Users Group: http://groups.google.com/group/nzphpug [2] [2]
To post, send email to [email protected]
To unsubscribe, send email to
[email protected]
---
You received this message because you are subscribed to the Google
Groups "NZ PHP Users Group" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out
[3] [3].
--
With best regards, Ivan Kurnosov
--
--
NZ PHP Users Group: http://groups.google.com/group/nzphpug [2] [2]
To post, send email to [email protected]
To unsubscribe, send email to
[email protected]
---
You received this message because you are subscribed to the Google
Groups "NZ PHP Users Group" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out
[3] [3].
--
--
NZ PHP Users Group: http://groups.google.com/group/nzphpug [2] [2]
To post, send email to [email protected]
To unsubscribe, send email to
[email protected]
---
You received this message because you are subscribed to the Google
Groups "NZ PHP Users Group" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out
[3] [3].
--
With best regards, Ivan Kurnosov
--
--
NZ PHP Users Group: http://groups.google.com/group/nzphpug [2] [2]
To post, send email to [email protected]
To unsubscribe, send email to
[email protected]
---
You received this message because you are subscribed to the Google
Groups "NZ PHP Users Group" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out
[3] [3].
Links:
------
[1]
http://blog.cribznetwork.com/2013/07/silverstripe-3-dos-vulnerable/
[1]
[2] http://groups.google.com/group/nzphpug [2]
[3] https://groups.google.com/groups/opt_out [3]
[4] http://cribznetwork.com [4]
--
--
NZ PHP Users Group: http://groups.google.com/group/nzphpug [2]
To post, send email to [email protected]
To unsubscribe, send email to
[email protected]
---
You received this message because you are subscribed to the Google
Groups "NZ PHP Users Group" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out [3].
Links:
------
[1] http://blog.cribznetwork.com/2013/07/silverstripe-3-dos-vulnerable/
[2] http://groups.google.com/group/nzphpug
[3] https://groups.google.com/groups/opt_out
[4] http://cribznetwork.com
--
--
NZ PHP Users Group: http://groups.google.com/group/nzphpug
To post, send email to [email protected]
To unsubscribe, send email to
[email protected]
---
You received this message because you are subscribed to the Google Groups "NZ PHP Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
