[Oisf-users] Protecting APIs

[Shirkdog]

What type of API's are you allowing to be exposed over the Internet?
You might have a security problem for which Suricata can never help
you with.

If you have a rock solid protected interface to your API calls, then
you could write up the specific bounds checking of your API calls to
ensure that only valid data is being send. But if it is encrypted,
Suricata would not be able to help. You will need something specific
to the host system to proxy the calls (mod_security, etc.)

---
Michael Shirk


On Tue, Aug 19, 2014 at 8:58 AM, Anoop Saldanha <anoopsaldanha at gmail.com> wrote:
> On Tue, Aug 19, 2014 at 5:53 PM, Ray Counterman <raycounterman at gmail.com> wrote:
>> In exposing APIs to clients over the Internet there is a different threat
>> model as APIs are fundamentally different from Web sites and have an
>> entirely unique risk profile that must be addressed.  Can Suricata help
>> protect against threats to APIs? Some examples are DoS; XML, SQL and Code
>> injection; Cross-site Scripting (XSS), and others.  Has anyone used Suricata
>> to protect APIs?
>>
>
> From where  I see, it should come down to running it inline(needs to
> be combined with active response for things like dos), or in active
> response(response reject), and writing meaningful rules.
>
> DoS: This can be tricky I suppose.  I can see cases where this needs
> direct support inside suricata, which it currently doesn't have. For
> example if I wanted to prevent slow dos, I would expect suricata to
> implement a timer/timeout againt a flow that matched on the said rule,
> and if a flow got stuck in a particular state or the stream didn't
> advance further, I would want suricata to timeout the flow, as well as
> send a RST down to the server and the client both.  I don't think
> there is a workaround either to support things like this.  This can be
> a feature though.
>
> xml - I don't think suricata has a xml parser.  Need to peek into
> libhtp to check this.
>
> sql, xss - Comes down to writing good rules.  Ideally for these 2
> cases, I would have wanted a keyword like
> http_args(https://redmine.openinfosecfoundation.org/issues/1194) to
> make life simple.  You can still write decent rules for this using the
> current http_* keywords we have.
>
> --
> -------------------------------
> Anoop Saldanha
> http://www.poona.me
> -------------------------------
> _______________________________________________
> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> OISF: http://www.openinfosecfoundation.org/