Interface with hosted security infrastructure about channelserver HOT 13 CLOSED

(Doing this accurately depends on #16)

from channelserver.

@jrconlin do you have any ideas in mind for how to apply rate-limiting for this service? Would you try to do it internally (maybe storing data into a shared redis instance?) or by talking to an external rate-limiting service?

from channelserver.

that introduces more coupling between this service and the rest of the FxA stack.

If the customs server were viewed along the lines of similar to 'iprepd', it's a dependency, but maybe one that's worthwhile.

from channelserver.

sigh. if secops ever does build a abuse tracking and mitigation system, I really hope they name it Godot.

@rfk No, I have no ideas or preferences for what sort of mitigation system we put in place. I suppose we should probably define what "abusive" behavior is. We've already got a few things in place for that, but I also wonder if in this time of bot farms and IPv6 addresses, if tracking per origin IP is reasonable?

FWIW, i'd kinda/sorta prefer a centralized abuse management system to keep us from re-inventing wheels, as well as preempt larger attacks.

from channelserver.

i'd kinda/sorta prefer a centralized abuse management system to keep us from re-inventing wheels,
as well as preempt larger attacks.

Me too! secops recently released their "iprepd" service for checking IP reputation, which isn't rate-limiting but is a step in that direction.

from channelserver.

We could integrate with the existing fxa-customs-server

Actually, this is not that easy in practice. We currently run fxa-customs-server as a "sidecar" service on the fxa-auth-server webheads, meaning that it's only available over localhost and not exposed to the broader network.

We could make a public-facing instance, but would need to figure out the security story for API calls, maybe using server-to-server secret keys.

I'm going to take this to the mailing list in order to loop others in on the discussion.

from channelserver.

We could make a public-facing instance, but would need to figure out the security story for API calls, maybe using server-to-server secret keys.

It could also be available only behind a VPN so not any goon could try to DDOS the service, even so server-to-server shared keys seems a responsible additional measure.

from channelserver.

This wasn't actually fixed in #31 in the end, re-opening.

from channelserver.

I thought that we agreed that we would use an outside system in order to restrict IP access? Doesn't that remove the need (or even the ability) for our server to do any sort of IP control?

from channelserver.

IIUC, we may still need to (1) parse and interpret a header provided by the security infrastructure, possibly rejecting requests as a result, and (2) log specific events about app-level misbehaviour to be interpreted by this infrastructure. I'll update the bug title accordingly.

from channelserver.

+1

Although I wonder if we should close this bug (and all the now invalid comments) and just start a new issue that talks about just doing that stuff.

from channelserver.

Sure, that makes sense; please file one as you see fit :-)

from channelserver.

Closing in favor of #34

from channelserver.