Beebs.systap added a comment. In https://phabricator.wikimedia.org/T90115#1143393, @csteipp wrote:
> Talked with Nik today about running this. We're planning to expose sending > raw queries into our cluster. > > The biggest threats are a malicious users causes data corruption or resource > consumption DoS, or an attacker is able to compromise the Blazegraph server > and pivot to the rest of our cluster. The data in Blazegraph is all public > (assuming we work out removing deleted/suppressed items), so authorization > within Blazegraph isn't a big concern. > > Mitigating those threats: > > - We want to make sure we are aware of security patches to Blazegraph, and > ops applies those in an appropriate timeframe. @Beebs.systap, is there a > special mailing list we need to be on to get notified? I haven't seen any > CVE's issued for Blazegraph, so I want to make sure we're watching the right > places. BB: We have not had a CVE issued directly against the Blazegraph (or predecessor) software. We have had a number of patches applied to versions of the libraries that had CVE on the included library. The commons-fileupload in release 1.3.2 was the most recent example. See [http://trac.bigdata.com/ticket/1010 Fileupload Security Fix]. We distribute these via the users mailing list and our internally maintained mailing lists. > - Since we know that we're running a more risky environment than most > Blazegraph users, it would be nice if we could ensure that if it's > compromised, the attacker can't start attacking the cluster. @joe, I know ops > isn't too fond of creating many new subnets for our services, but since we're > starting from scratch, is this a case where we can put the boxes on a > dedicated subnet and make sure the other mediawiki infrastructure isn't > directly routable from there? > - In blazegraph, @manybubbles is looking into what options need to be > disabled to prevent queries from, > - modify existing data > - opening external or internal resources (it sounds like there might be > capabilities to cause Blazegraph to query an external db, or load local files) > - At the application (proxy?) layer, we'll setup some per-ip/user throttles, > and make sure we set appropriate timeouts > - We'll make sure revision deletion is working correctly so we don't leak > suppressed items TASK DETAIL https://phabricator.wikimedia.org/T90115 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: csteipp, Beebs.systap Cc: Thompsonbry.systap, Smalyshev, Joe, Liuxinyu970226, csteipp, Beebs.systap, Haasepeter, Aklapper, Manybubbles, jkroll, Wikidata-bugs, Jdouglas, aude, GWicke, daniel, JanZerebecki _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
